aboutsummaryrefslogtreecommitdiff
path: root/contrib/ncurses/misc
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/ncurses/misc')
-rw-r--r--contrib/ncurses/misc/Makefile.in108
-rw-r--r--contrib/ncurses/misc/chkdef.cmd86
-rw-r--r--contrib/ncurses/misc/cleantic.cmd16
-rw-r--r--contrib/ncurses/misc/cmpdef.cmd106
-rw-r--r--contrib/ncurses/misc/emx.src812
-rw-r--r--contrib/ncurses/misc/form.def105
-rw-r--r--contrib/ncurses/misc/form.ref106
-rw-r--r--contrib/ncurses/misc/hackguide.doc694
-rw-r--r--contrib/ncurses/misc/hackguide.html883
-rw-r--r--contrib/ncurses/misc/makedef.cmd151
-rwxr-xr-xcontrib/ncurses/misc/makellib162
-rw-r--r--contrib/ncurses/misc/menu.def84
-rw-r--r--contrib/ncurses/misc/menu.ref73
-rw-r--r--contrib/ncurses/misc/ncurses-intro.doc2530
-rw-r--r--contrib/ncurses/misc/ncurses-intro.html2682
-rw-r--r--contrib/ncurses/misc/ncurses.def442
-rw-r--r--contrib/ncurses/misc/ncurses.ref572
-rw-r--r--contrib/ncurses/misc/panel.def25
-rw-r--r--contrib/ncurses/misc/panel.ref18
-rwxr-xr-xcontrib/ncurses/misc/run_tic.sh159
-rwxr-xr-xcontrib/ncurses/misc/shlib82
-rw-r--r--contrib/ncurses/misc/tabset/std1
-rw-r--r--contrib/ncurses/misc/tabset/stdcrt1
-rw-r--r--contrib/ncurses/misc/tabset/vt1003
-rw-r--r--contrib/ncurses/misc/tabset/vt3003
-rwxr-xr-xcontrib/ncurses/misc/tdlint111
-rw-r--r--contrib/ncurses/misc/terminfo.src17257
27 files changed, 27272 insertions, 0 deletions
diff --git a/contrib/ncurses/misc/Makefile.in b/contrib/ncurses/misc/Makefile.in
new file mode 100644
index 000000000000..2b6d2e62ea25
--- /dev/null
+++ b/contrib/ncurses/misc/Makefile.in
@@ -0,0 +1,108 @@
+# $Id: Makefile.in,v 1.20 1998/02/11 12:13:52 tom Exp $
+##############################################################################
+# Copyright (c) 1998 Free Software Foundation, Inc. #
+# #
+# Permission is hereby granted, free of charge, to any person obtaining a #
+# copy of this software and associated documentation files (the "Software"), #
+# to deal in the Software without restriction, including without limitation #
+# the rights to use, copy, modify, merge, publish, distribute, distribute #
+# with modifications, sublicense, and/or sell copies of the Software, and to #
+# permit persons to whom the Software is furnished to do so, subject to the #
+# following conditions: #
+# #
+# The above copyright notice and this permission notice shall be included in #
+# all copies or substantial portions of the Software. #
+# #
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR #
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, #
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL #
+# THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER #
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING #
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER #
+# DEALINGS IN THE SOFTWARE. #
+# #
+# Except as contained in this notice, the name(s) of the above copyright #
+# holders shall not be used in advertising or otherwise to promote the sale, #
+# use or other dealings in this Software without prior written #
+# authorization. #
+##############################################################################
+#
+# Author: Thomas E. Dickey <dickey@clark.net> 1996,1997
+#
+# Makefile for ncurses miscellany directory
+#
+# This makes/installs the terminfo database
+#
+# The variable 'srcdir' refers to the source-distribution, and can be set with
+# the configure script by "--srcdir=DIR".
+#
+# The rules are organized to produce the libraries for the configured models,
+# and the programs with the configured default model.
+
+# turn off _all_ suffix rules; we'll generate our own
+.SUFFIXES:
+
+SHELL = /bin/sh
+THIS = Makefile
+
+CF_MFLAGS = @cf_cv_makeflags@
+@SET_MAKE@
+
+INSTALL_PREFIX = @INSTALL_PREFIX@
+srcdir = @srcdir@
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+bindir = @bindir@
+libdir = @libdir@
+datadir = @datadir@
+
+tabsetdir = $(datadir)/tabset
+ticdir = $(datadir)/terminfo
+
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
+
+################################################################################
+all:
+
+sources:
+
+install: install.data
+
+install.data: $(INSTALL_PREFIX)$(libdir) \
+ $(INSTALL_PREFIX)$(ticdir) \
+ $(INSTALL_PREFIX)$(tabsetdir)
+ sh $(srcdir)/run_tic.sh $(bindir) $(srcdir) $(ticdir) $(INSTALL_PREFIX)
+ @cd $(srcdir)/tabset && \
+ sh -c 'for i in `echo * | fgrep -v CVS | fgrep -v RCS`; do \
+ echo installing $$i; \
+ $(INSTALL_DATA) $$i $(INSTALL_PREFIX)$(tabsetdir); done'
+
+$(INSTALL_PREFIX)$(libdir) \
+$(INSTALL_PREFIX)$(tabsetdir) \
+$(INSTALL_PREFIX)$(ticdir) :
+ $(srcdir)/../mkinstalldirs $@
+
+uninstall: uninstall.data
+
+uninstall.data:
+ -cd $(INSTALL_PREFIX)$(ticdir) && rm -rf *
+ -cd $(INSTALL_PREFIX)$(tabsetdir) && rm -rf *
+
+tags:
+
+TAGS:
+
+mostlyclean:
+ -rm -f core tags TAGS *~ *.ln *.atac trace
+
+clean :: mostlyclean
+
+distclean: clean
+ -rm -f Makefile
+
+realclean: distclean
+
+###############################################################################
+# The remainder of this file is automatically generated during configuration
+###############################################################################
diff --git a/contrib/ncurses/misc/chkdef.cmd b/contrib/ncurses/misc/chkdef.cmd
new file mode 100644
index 000000000000..c8d743356d6c
--- /dev/null
+++ b/contrib/ncurses/misc/chkdef.cmd
@@ -0,0 +1,86 @@
+/*
+ * $Id: chkdef.cmd,v 1.2 1998/08/29 21:45:58 tom Exp $
+ *
+ * Author: Juan Jose Garcia Ripoll <worm@arrakis.es>.
+ * Webpage: http://www.arrakis.es/~worm/
+ *
+ * chkdef.cmd - checks that a .def file has no conflicts and is properly
+ * formatted.
+ *
+ * returns nonzero if two symbols have the same code or a line has a wrong
+ * format.
+ *
+ * returns 0 otherwise
+ *
+ * the standard output shows conflicts.
+ */
+parse arg def_file
+
+def_file = translate(def_file,'\','/')
+
+call CleanQueue
+
+/*
+ * `cmp' is zero when the file is valid
+ * `codes' associates a name to a code
+ * `names' associates a code to a name
+ */
+cmp = 0
+codes. = 0
+names. = ''
+
+/*
+ * This sed expression cleans empty lines, comments and special .DEF
+ * commands, such as LIBRARY..., EXPORTS..., etc
+ */
+tidy_up = '"s/[ ][ ]*/ /g;s/;.*//g;/^[ ]*$/d;/^[a-zA-Z]/d;"'
+
+/*
+ * First we find all public symbols from the original DLL. All this
+ * information is pushed into a REXX private list with the RXQUEUE
+ * utility program.
+ */
+'@echo off'
+'type' def_file '| sed' tidy_up '| sort | rxqueue'
+
+do while queued() > 0
+ /*
+ * We retrieve the symbol name (NEW_NAME) and its code (NEW_CODE)
+ */
+ parse pull '"' new_name '"' '@'new_code rest
+ select
+ when (new_code = '') | (new_name = '') then
+ /* The input was not properly formatted */
+ do
+ say 'Error: symbol "'new_name'" has no export code or is empty'
+ cmp = 1
+ end
+ when codes.new_name \= 0 then
+ /* This symbol was already defined */
+ if codes.new_name \= new_code then
+ do
+ cmp = 2
+ say 'Symbol "'new_name'" multiply defined'
+ end
+ when names.new_code \= '' then
+ /* This code was already assigned to a symbol */
+ if names.new_code \= new_name then
+ do
+ cmp = 3
+ say 'Conflict with "'names.new_code'" & "'new_name'" being @'new_code
+ end
+ otherwise
+ do
+ codes.new_name = new_code
+ names.new_code = new_name
+ end
+ end /* select */
+end
+
+exit cmp
+
+CleanQueue: procedure
+ do while queued() > 0
+ parse pull foo
+ end
+return
diff --git a/contrib/ncurses/misc/cleantic.cmd b/contrib/ncurses/misc/cleantic.cmd
new file mode 100644
index 000000000000..ab6a40a4fc88
--- /dev/null
+++ b/contrib/ncurses/misc/cleantic.cmd
@@ -0,0 +1,16 @@
+/*
+ * $Id: cleantic.cmd,v 1.3 1998/08/29 21:43:19 tom Exp $
+ *
+ * Author: Juan Jose Garcia Ripoll <worm@arrakis.es>.
+ * Webpage: http://www.arrakis.es/~worm/
+ */
+parse arg dir
+
+pause
+dir = translate(dir,'\','/');
+letters = '0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j k l m n o p q r s t u v w x y z'
+
+if dir = '' then
+ dir = '.'
+'echo Cleaning 'dir
+'for %%1 in ('letters') do @if not exist 'dir'\%%1\* (echo Cleaning ...\%%1 & rd %%1 2>NUL)'
diff --git a/contrib/ncurses/misc/cmpdef.cmd b/contrib/ncurses/misc/cmpdef.cmd
new file mode 100644
index 000000000000..7cc9c95cc475
--- /dev/null
+++ b/contrib/ncurses/misc/cmpdef.cmd
@@ -0,0 +1,106 @@
+/*
+ * $Id: cmpdef.cmd,v 1.2 1998/08/29 21:44:47 tom Exp $
+ *
+ * Author: Juan Jose Garcia Ripoll <worm@arrakis.es>.
+ * Webpage: http://www.arrakis.es/~worm/
+ *
+ * cmpdef.cmd - compares two .def files, checking whether they have
+ * the same entries with the same export codes.
+ *
+ * returns 0 if there are no conflicts between the files -- that is,
+ * the newer one can replace the older one.
+ *
+ * returns 1 when either of the files is not properly formatted and
+ * when there are conflicts: two symbols having the same export code.
+ *
+ * the standard output shows a list with newly added symbols, plus
+ * replaced symbols and conflicts.
+ */
+parse arg def_file1 def_file2
+
+def_file1 = translate(def_file1,'\','/')
+def_file2 = translate(def_file2,'\','/')
+
+call CleanQueue
+
+/*
+ * `cmp' is zero when the last file is valid and upward compatible
+ * `numbers' is the stem where symbols are stored
+ */
+cmp = 0
+names. = ''
+numbers. = 0
+
+/*
+ * This sed expression cleans empty lines, comments and special .DEF
+ * commands, such as LIBRARY..., EXPORTS..., etc
+ */
+tidy_up = '"s/[ ][ ]*/ /g;s/;.*//g;/^[ ]*$/d;/^[a-zA-Z]/d;"'
+
+/*
+ * First we find all public symbols from the original DLL. All this
+ * information is pushed into a REXX private list with the RXQUEUE
+ * utility program.
+ */
+'@echo off'
+'type' def_file1 '| sed' tidy_up '| sort | rxqueue'
+
+do while queued() > 0
+ /*
+ * We retrieve the symbol name (NAME) and its number (NUMBER)
+ */
+ parse pull '"' name '"' '@'number rest
+ if number = '' || name = '' then
+ do
+ say 'Corrupted file' def_file1
+ say 'Symbol' name 'has no number'
+ exit 1
+ end
+ else
+ do
+ numbers.name = number
+ names.number = name
+ end
+end
+
+/*
+ * Now we find all public symbols from the new DLL, and compare.
+ */
+'type' def_file2 '| sed' tidy_up '| sort | rxqueue'
+
+do while queued() > 0
+ parse pull '"' name '"' '@'number rest
+ if name = '' | number = '' then
+ do
+ say 'Corrupted file' def_file2
+ say 'Symbol' name 'has no number'
+ exit 1
+ end
+ if numbers.name = 0 then
+ do
+ cmp = 1
+ if names.number = '' then
+ say 'New symbol' name 'with code @'number
+ else
+ say 'Conflict old =' names.number ', new =' name 'at @'number
+ end
+ else if numbers.name \= number then
+ do
+ cmp = 1
+ say name 'Symbol' name 'changed from @'numbers.name 'to @'number
+ end
+end /* do */
+
+exit cmp
+
+/*
+ * Cleans the REXX queue by pulling and forgetting every line.
+ * This is needed, at least, when `cmpdef.cmd' starts, because an aborted
+ * REXX program might have left some rubbish in.
+ */
+CleanQueue: procedure
+ do while queued() > 0
+ parse pull foo
+ end
+return
+
diff --git a/contrib/ncurses/misc/emx.src b/contrib/ncurses/misc/emx.src
new file mode 100644
index 000000000000..7319f5d83cf8
--- /dev/null
+++ b/contrib/ncurses/misc/emx.src
@@ -0,0 +1,812 @@
+# $Id: emx.src,v 1.6 1999/08/15 01:56:54 tom Exp $
+# This is a reformatted copy of the terminfo source for OS/2 EMX from
+# Juan Jose Garcia Ripoll <worm@arrakis.es>.
+# http://www.arrakis.es/~worm/
+#----------------------------------------------------------------------------
+#
+# This section describes terminal classes and maker brands that are still
+# quite common.
+#
+
+#### Specials
+#
+# Special "terminals". These are used to label tty lines when you don't
+# know what kind of terminal is on it. The characteristics of an unknown
+# terminal are the lowest common denominator - they look about like a ti 700.
+#
+
+dumb|80-column dumb tty,
+ am,
+ cols#80,
+ bel=^G,
+ cr=^M,
+ cud1=^J,
+ ind=^J,
+unknown|unknown terminal type,
+ gn,
+ use=dumb,
+lpr|printer|line printer,
+ hc,
+ os,
+ cols#132,
+ lines#66,
+ bel=^G,
+ cr=^M,
+ cub1=^H,
+ cud1=^J,
+ ff=^L,
+ ind=^J,
+glasstty|classic glass tty interpreting ASCII control characters,
+ am,
+ cols#80,
+ bel=^G,
+ clear=^L,
+ cr=^M,
+ cub1=^H,
+ cud1=^J,
+ ht=^I,
+ kbs=^H,
+ kcub1=^H,
+ kcud1=^J,
+ nel=^M^J,
+
+#### ANSI.SYS/ISO 6429/ECMA-48 Capabilities
+#
+# See the end-of-file comment for more on these.
+#
+
+# The IBM PC alternate character set. Plug this into any Intel console entry.
+# We use \E[11m for rmacs rather than \E[12m so the <acsc> string can use the
+# ROM graphics for control characters such as the diamond, up- and down-arrow.
+# This works with the System V, Linux, and BSDI consoles. It's a safe bet this
+# will work with any Intel console, they all seem to have inherited \E[11m
+# from the ANSI.SYS de-facto standard.
+klone+acs|alternate character set for ansi.sys displays,
+ acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
+ rmacs=\E[10m,
+ smacs=\E[11m,
+
+# Highlight controls corresponding to the ANSI.SYS standard. Most
+# console drivers for Intel boxes obey these. Makes the same assumption
+# about \E[11m as klone+acs. True ANSI/ECMA-48 would have <rmso=\E[27m>,
+# <rmul=\E[24m>, but this isn't a documented feature of ANSI.SYS.
+klone+sgr|attribute control for ansi.sys displays,
+ blink=\E[5m,
+ bold=\E[1m,
+ invis=\E[8m,
+ rev=\E[7m,
+ rmacs=\E[10m,
+ rmpch=\E[10m,
+ rmso=\E[m,
+ rmul=\E[m,
+ sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m,
+ sgr0=\E[0;10m,
+ smacs=\E[11m,
+ smpch=\E[11m,
+ smso=\E[7m,
+ smul=\E[4m,
+
+# Highlight controls corresponding to the ANSI.SYS standard. *All*
+# console drivers for Intel boxes obey these. Does not assume \E[11m will
+# work; uses \E[12m instead, which is pretty bulletproof but loses you the ACS
+# diamond and arrow characters under curses.
+klone+sgr-dumb|attribute control for ansi.sys displays (no ESC [ 11 m),
+ blink=\E[5m,
+ bold=\E[1m,
+ invis=\E[8m,
+ rev=\E[7m,
+ rmacs=\E[10m,
+ rmso=\E[m,
+ rmul=\E[m,
+ sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;12%;m,
+ sgr0=\E[0;10m,
+ smacs=\E[12m,
+ smso=\E[7m,
+ smul=\E[4m,
+
+# ANSI.SYS color control.
+# The DOS 5 manual asserts that these sequences meet the ISO 6429 standard.
+klone+color|color control for ansi.sys and ISO6429-compatible displays,
+ colors#8,
+ ncv#3,
+ pairs#64,
+ op=\E[37;40m,
+ setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm,
+ setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+
+#### ANSI/ECMA-48 terminals and terminal emulators
+#
+# See near the end of this file for details on ANSI conformance.
+# Don't mess with these entries! Lots of other entries depend on them!
+#
+# This section lists entries in a least-capable to most-capable order.
+# if you're in doubt about what `ANSI' matches yours, try them in that
+# order and back off from the first that breaks.
+
+ansi-mini|any ansi terminal with pessimistic assumptions,
+ am,
+ cols#80,
+ it#8,
+ lines#24,
+ clear=\E[H\E[2J$<50>,
+ cub1=\E[D,
+ cud1=\E[B,
+ cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A,
+ el=\E[K,
+ home=\E[H,
+ ht=^I,
+
+#
+# ANSI.SYS entries
+#
+# This completely describes the sequences specified in the DOS 2.1 ANSI.SYS
+# documentation (except for the keyboard key reassignment feature, which
+# doen't fit the <pfkey> model well). The klone+acs sequences were valid
+# though undocumented. The <pfkey> capability is untested but should work for
+# keys F1-F10 (%p1 values outside this range will yield unpredictable results).
+# From: Eric S. Raymond <esr@snark.thyrsus.com> Nov 7 1995
+ansi.sys-old|ANSI.SYS under PC-DOS 2.1,
+ am,
+ mir,
+ msgr,
+ xon,
+ cols#80,
+ lines#25,
+ clear=\E[2J,
+ cub1=^H,
+ cud1=\E[B,
+ cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A,
+ el=\E[k,
+ home=\E[H,
+ is2=\E[m\E[?7h,
+ kcub1=^H,
+ kcud1=^J,
+ kcuf1=^L,
+ kcuu1=^K,
+ khome=^^,
+ pfkey=\E[0;%p1%{58}%+%d;%p2"%s",
+ rc=\E[u,
+ rmam=\E[?7l,
+ sc=\E[s,
+ smam=\E[?7h,
+ u6=\E[%i%d;%dR,
+ u7=\E[6n,
+ use=klone+color,
+ use=klone+acs,
+ use=klone+sgr,
+ansi.sys|ANSI.SYS 3.1 and later versions,
+ el=\E[K,
+ use=ansi.sys-old,
+
+### EMX termcap.dat compatibility modes
+#
+# Keypad: Home=\0G Up=\0H PrPag=\0I
+# ka1,kh kcuu1 kpp,ka3
+#
+# Left=\0K 5=\0L Right=\0M
+# kcub1 kb2 kcuf1
+#
+# End=\0O Down=\0P NxPag=\0Q
+# kc1,kend kcud1 kc3,knp
+#
+# Ins=\0R Del=\0S
+# kich1 kdch1
+#
+# On keyboard with 12 function keys,
+# shifted f-keys: F13-F24
+# control f-keys: F25-F36
+# alt f-keys: F37-F48
+# The shift/control/alt keys do not modify each other, but alt overrides both,
+# and control overrides shift.
+#
+# Also (possibly only EMX, so we don't put it in ansi.sys, etc): set the
+# no_color_video to inform the application that standout(1), underline(2)
+# reverse(4) and invisible(64) don't work with color.
+emx-base|DOS special keys,
+ bw,
+ ncv#71,
+ bel=^G,
+ ka1=\0G,
+ ka3=\0I,
+ kb2=\0L,
+ kbs=^H,
+ kc1=\0O,
+ kc3=\0Q,
+ kcbt=\0^O,
+ kcub1=\0K,
+ kcud1=\0P,
+ kcuf1=\0M,
+ kcuu1=\0H,
+ kdch1=\0S,
+ kend=\0O,
+ kf1=\0;,
+ kf10=\0D,
+ kf11=\0\205,
+ kf12=\0\206,
+ kf13=\0T,
+ kf14=\0U,
+ kf15=\0V,
+ kf16=\0W,
+ kf17=\0X,
+ kf18=\0Y,
+ kf19=\0Z,
+ kf2=\0<,
+ kf20=\0[,
+ kf21=\0\\,
+ kf22=\0],
+ kf23=\0\207,
+ kf24=\0\210,
+ kf25=\0\^,
+ kf26=\0_,
+ kf27=\0`,
+ kf28=\0a,
+ kf29=\0b,
+ kf3=\0=,
+ kf30=\0c,
+ kf31=\0d,
+ kf32=\0e,
+ kf33=\0f,
+ kf34=\0g,
+ kf35=\0\211,
+ kf36=\0\212,
+ kf37=\0h,
+ kf38=\0i,
+ kf39=\0j,
+ kf4=\0>,
+ kf40=\0k,
+ kf41=\0l,
+ kf42=\0m,
+ kf43=\0n,
+ kf44=\0o,
+ kf45=\0p,
+ kf46=\0q,
+ kf47=\0\213,
+ kf48=\0\214,
+ kf5=\0?,
+ kf6=\0@,
+ kf7=\0A,
+ kf8=\0B,
+ kf9=\0C,
+ khome=\0G,
+ kich1=\0R,
+ knp=\0Q,
+ kpp=\0I,
+ use=ansi.sys,
+#
+# To properly translate termcap.dat -> terminfo.src remember these
+# equivalences:
+# ti <-> smcup string to start programs using cup(termcap)
+# te <-> rmcup string to end programs using cup
+# so <-> smso begin standout mode
+# se <-> rmso exit standout mode
+# us <-> smul begin underline mode
+# ue <-> rmul exit underline mode
+# mb <-> blink turn on blinking
+# md <-> bold turn on extra bright (bold) mode
+# mr <-> rev turn on reverse video mode
+# me <-> sgr0 turn off all atributes
+#
+# On my terminal, \E[4m looks dim.
+ansi|ANSI.SYS color,
+ blink=\E[5m,
+ bold=\E[1m,
+ kmous=\E[M,
+ rev=\E[7m,
+ rmcup=\E[0m,
+ rmso=\E[0m,
+ rmul@,
+ sgr0=\E[0m,
+ smcup=\E[0;37;40m,
+ smso=\E[7m,
+ smul@,
+ use=emx-base,
+window|ANSI.SYS window,
+ blink=\E[5m,
+ bold=\E[1;37;47m,
+ rev=\E[1;37;47m,
+ rmcup=\E[0m,
+ rmso=\E[0;37;40m,
+ rmul=\E[0;37;40m,
+ sgr0=\E[0;37;40m,
+ smcup=\E[0;37;40m,
+ smso=\E[1;37;47m,
+ smul=\E[1;31;47m,
+ use=emx-base,
+mono|ANSI.SYS mono,
+ blink=\E[5m,
+ bold=\E[1m,
+ rev=\E[7m,
+ rmcup=\E[0m,
+ rmso=\E[m,
+ rmul=\E[m,
+ sgr0=\E[m,
+ smcup=\E[0m,
+ smso=\E[1m,
+ smul=\E[4m,
+ use=emx-base,
+# same as mono, but use reverse video for standout (nice for Emacs)
+rmono|ANSI.SYS reverse mono,
+ smso=\E[7m,
+ use=mono,
+# same as mono, but use a readable color for underlining
+mono2|ANSI.SYS mono2,
+ rmul=\E[0m,
+ smul=\E[1;31;40m,
+ use=mono,
+# nice colors for Emacs (white on blue, mode line white on cyan)
+ansi-color-2|ANSI.SYS color 2,
+ rmcup=\E[0m,
+ rmso=\E[0;37;44m,
+ rmul=\E[0m,
+ sgr0=\E[0;37;44m,
+ smcup=\E[0;37;44m,
+ smso=\E[1;37;46m,
+ smul=\E[1;31;40m,
+ use=ansi,
+# nice colors for Emacs (white on black, mode line black on cyan)
+ansi-color-3|ANSI.SYS color 3,
+ rmcup=\E[0m,
+ rmso=\E[0m,
+ rmul=\E[0m,
+ sgr0=\E[0m,
+ smcup=\E[0m,
+ smso=\E[30;46m,
+ smul=\E[1;31;40m,
+ use=ansi,
+
+#### X terminal emulators
+#
+# X10/6.6 11/7/86, minus alternate screen, plus (csr)
+# (xterm: ":MT:" changed to ":km:"; added <smam>/<rmam> based on init string;
+# removed (hs, eslok, tsl=\E[?E\E[?%i%dT, fsl=\E[?F, dsl=\E[?E)
+# as these seem not to work -- esr)
+x10term|vs100-x10|xterm terminal emulator (X10 window system),
+ am,
+ km,
+ mir,
+ msgr,
+ xenl,
+ xon,
+ cols#80,
+ it#8,
+ lines#65,
+ bold=\E[1m,
+ clear=\E[H\E[2J,
+ csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H,
+ cud1=^J,
+ cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A,
+ dch=\E[%p1%dP,
+ dch1=\E[P,
+ dl=\E[%p1%dM,
+ dl1=\E[M,
+ ed=\E[J,
+ el=\E[K,
+ home=\E[H,
+ ht=^I,
+ il=\E[%p1%dL,
+ il1=\E[L,
+ ind=^J,
+ is2=\E\E[m\E[?7h\E[?1;4l,
+ kbs=^H,
+ kcub1=\EOD,
+ kcud1=\EOB,
+ kcuf1=\EOC,
+ kcuu1=\EOA,
+ kf1=\EOP,
+ kf2=\EOQ,
+ kf3=\EOR,
+ kf4=\EOS,
+ rev=\E[7m,
+ ri=\EM,
+ rmam=\E[?7l,
+ rmir=\E[4l,
+ rmkx=\E[?1l\E>,
+ rmso=\E[m,
+ rmul=\E[m,
+ sgr0=\E[m,
+ smam=\E[?7h,
+ smir=\E[4h,
+ smkx=\E[?1h\E=,
+ smso=\E[7m,
+ smul=\E[4m,
+# X11R6 xterm. This is known good for the XFree86 version under Linux.
+# It is *way* more featureful than the stock X consortium entry (has acsc,
+# for starters). The <kmous> key is actually the \E[M prefix returned by
+# xterm's internal mouse-tracking facility; ncurses will interpret the
+# following three bytes of mouse status information.
+# From: Eric S. Raymond <esr@snark.thyrsus.com> 14 Dec 1995
+xterm|vs100|xterm terminal emulator (X11R6 Window System),
+ am,
+ km,
+ mir,
+ msgr,
+ xenl,
+ xon,
+ cols#80,
+ it#8,
+ lines#65,
+ acsc=++\,\,--..00II``aaffgghhjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G,
+ bold=\E[1m,
+ clear=\E[H\E[2J,
+ cr=^M,
+ csr=\E[%i%p1%d;%p2%dr,
+ cub=\E[%p1%dD,
+ cub1=^H,
+ cud=\E[%p1%dB,
+ cud1=^J,
+ cuf=\E[%p1%dC,
+ cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH,
+ cuu=\E[%p1%dA,
+ cuu1=\E[A,
+ dch=\E[%p1%dP,
+ dch1=\E[P,
+ dl=\E[%p1%dM,
+ dl1=\E[M,
+ ed=\E[J,
+ el=\E[K,
+ enacs=\E(B\E)0,
+ home=\E[H,
+ ht=^I,
+ ich=\E[%p1%d@,
+ ich1=\E[@,
+ il=\E[%p1%dL,
+ il1=\E[L,
+ ind=^J,
+ is2=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l,
+ kbs=^H,
+ kcub1=\EOD,
+ kcud1=\EOB,
+ kcuf1=\EOC,
+ kcuu1=\EOA,
+ kend=\EOe,
+ kent=\EOM,
+ kf1=\E[11~,
+ kf10=\E[21~,
+ kf11=\E[23~,
+ kf12=\E[24~,
+ kf2=\E[12~,
+ kf3=\E[13~,
+ kf4=\E[14~,
+ kf5=\E[15~,
+ kf6=\E[17~,
+ kf7=\E[18~,
+ kf8=\E[19~,
+ kf9=\E[20~,
+ khome=\EO\0,
+ kich1=\E[2~,
+ kmous=\E[M,
+ knp=\E[6~,
+ kpp=\E[5~,
+ rc=\E8,
+ rev=\E[7m,
+ ri=\EM,
+ rmacs=^O,
+ rmam=\E[?7l,
+ rmcup=\E[2J\E[?47l\E8,
+ rmir=\E[4l,
+ rmkx=\E[?1l\E>,
+ rmso=\E[m,
+ rmul=\E[m,
+ rs1=^O,
+ rs2=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l\E<,
+ sc=\E7,
+ sgr0=\E[m,
+ smacs=^N,
+ smam=\E[?7h,
+ smcup=\E7\E[?47h,
+ smir=\E[4h,
+ smkx=\E[?1h\E=,
+ smso=\E[7m,
+ smul=\E[4m,
+ tbc=\E[3k,
+ u6=\E[%i%d;%dR,
+ u7=\E[6n,
+ u8=\E[?1;2c,
+ u9=\E[c,
+xterm-bold|xterm terminal emulator (X11R6 Window System) standout w/bold,
+ smso=\E[1m,
+ use=xterm,
+xterms|vs100s|xterm terminal emulator (small screen 24x80),
+ cols#80,
+ lines#24,
+ use=xterm,
+# (kterm: this had extension capabilities ":KJ:TY=ascii:" -- esr)
+kterm|kterm kanji terminal emulator (X window system),
+ eslok,
+ hs,
+ csr=\E[%i%p1%d;%p2%dr,
+ dsl=\E[?H,
+ fsl=\E[?F,
+ rc=\E8,
+ sc=\E7,
+ tsl=\E[?E\E[?%i%dT,
+ use=xterm,
+
+# See the note on ICH/ICH1 VERSUS RMIR/SMIR near the end of file
+xterm-nic|xterm with ich/ich1 suppressed for non-curses programs,
+ ich@,
+ ich1@,
+ use=xterm,
+
+# Should work with the color xterm on the X11R6 contrib tape.
+# Assumes the xterm attribute default is black on white.
+# From: Eric S. Raymond <esr@snark.thyrsus.com> March 4 1996
+xterm-color|xterm with color support,
+ op=\E[30;47m,
+ use=xterm,
+ use=klone+color,
+
+# From: Thomas Dickey <dickey@clark.net> 13 Dec 1995
+rxvt|rxvt terminal emulator,
+ kend=\EOw,
+ khome=\E[H,
+ kmous@,
+ use=xterm,
+ use=klone+color,
+
+# From: David J. MacKenzie <djm@va.pubnix.com> 20 Apr 1995
+# Here's a termcap entry I've been using for xterm_color, which comes
+# with BSD/OS 2.0, and the X11R6 contrib tape too I think. Besides the
+# color stuff, I also have a status line defined as the window manager
+# title bar. [I have translated it to terminfo -- ESR]
+xterm-pcolor|xterm with color used for highlights and status line,
+ hs,
+ wsl#40,
+ bold=\E[1m\E[43m,
+ dsl=\E]0;\007,
+ fsl=^G,
+ rev=\E[7m\E[34m,
+ smso=\E[7m\E[31m,
+ smul=\E[4m\E[42m,
+ tsl=\E]0;,
+ use=xterm,
+
+# HP ships this, except for the pb#9600 which was merged in from BSD termcap.
+hpterm|X-hpterm|hp X11 terminal emulator,
+ am,
+ da,
+ db,
+ mir,
+ xhp,
+ cols#80,
+ lh#2,
+ lines#24,
+ lm#0,
+ lw#8,
+ nlab#8,
+ pb#9600,
+ xmc#0,
+ bel=^G,
+ bold=\E&dB,
+ cbt=\Ei,
+ clear=\E&a0y0C\EJ,
+ cr=^M,
+ cub1=^H,
+ cud1=\EB,
+ cuf1=\EC,
+ cup=\E&a%p1%dy%p2%dC,
+ cuu1=\EA,
+ dch1=\EP,
+ dim=\E&dH,
+ dl1=\EM,
+ ed=\EJ$<1>,
+ el=\EK,
+ hpa=\E&a%p1%dC,
+ ht=^I,
+ hts=\E1,
+ il1=\EL,
+ ind=^J,
+ kbs=^H,
+ kclr=\EJ,
+ kctab=\E2,
+ kcub1=\ED,
+ kcud1=\EB,
+ kcuf1=\EC,
+ kcuu1=\EA,
+ kdch1=\EP,
+ kdl1=\EM,
+ ked=\EJ,
+ kel=\EK,
+ kf1=\Ep,
+ kf2=\Eq,
+ kf3=\Er,
+ kf4=\Es,
+ kf5=\Et,
+ kf6=\Eu,
+ kf7=\Ev,
+ kf8=\Ew,
+ khome=\Eh,
+ khts=\E1,
+ kich1=\EQ,
+ kil1=\EL,
+ kind=\ES,
+ kll=\EF,
+ knp=\EU,
+ kpp=\EV,
+ kri=\ET,
+ krmir=\ER,
+ ktbc=\E3,
+ meml=\El,
+ memu=\Em,
+ pfkey=\E&f%p1%dk%p2%l%dL%p2%s,
+ pfloc=\E&f1a%p1%dk%p2%l%dL%p2%s,
+ pfx=\E&f2a%p1%dk%p2%l%dL%p2%s,
+ pln=\E&f%p1%dk%p2%l%dd0L%p2%s,
+ rev=\E&dB,
+ ri=\ET,
+ rmacs=^O,
+ rmir=\ER,
+ rmkx=\E&s0A,
+ rmln=\E&j@,
+ rmso=\E&d@,
+ rmul=\E&d@,
+ sgr=\E&d%?%p7%t%'s'%c%;%p1%p3%|%p6%|%{2}%*%p2%{4}%*%+%p4%+%p5%{8}%*%+%'@'%+%c%?%p9%t%'\016'%c%e%'\017'%c%;,
+ sgr0=\E&d@,
+ smacs=^N,
+ smir=\EQ,
+ smkx=\E&s1A,
+ smln=\E&jB,
+ smso=\E&dJ,
+ smul=\E&dD,
+ tbc=\E3,
+ vpa=\E&a%p1%dY,
+
+# This entry describes an xterm with Sun-style function keys enabled
+# via the X resource setting "xterm*sunFunctionKeys:true"
+# To understand <kf11>/<kf12> note that L1,L2 and F11,F12 are the same.
+# The <kf13>...<kf20> keys are L3-L10. We don't set <kf16=\E[197z>
+# because we want it to be seen as <kcpy>.
+# The <kf31>...<kf45> keys are R1-R15. We treat some of these in accordance
+# with their Sun keyboard labels instead.
+# From: Simon J. Gerraty <sjg@zen.void.oz.au> 10 Jan 1996
+xterm-sun|xterm with sunFunctionKeys true,
+ kb2=\E[218z,
+ kcpy=\E[197z,
+ kend=\E[220z,
+ kf1=\E[224z,
+ kf10=\E[233z,
+ kf11=\E[192z,
+ kf12=\E[193z,
+ kf13=\E[194z,
+ kf14=\E[195z,
+ kf15=\E[196z,
+ kf17=\E[198z,
+ kf18=\E[199z,
+ kf19=\E[200z,
+ kf2=\E[225z,
+ kf20=\E[201z,
+ kf3=\E[226z,
+ kf31=\E[208z,
+ kf32=\E[209z,
+ kf33=\E[210z,
+ kf34=\E[211z,
+ kf35=\E[212z,
+ kf36=\E[213z,
+ kf38=\E[215z,
+ kf4=\E[227z,
+ kf40=\E[217z,
+ kf42=\E[219z,
+ kf44=\E[221z,
+ kf5=\E[228z,
+ kf6=\E[229z,
+ kf7=\E[230z,
+ kf8=\E[231z,
+ kf9=\E[232z,
+ kfnd=\E[200z,
+ khlp=\E[196z,
+ khome=\E[214z,
+ kich1=\E[2z,
+ knp=\E[222z,
+ kpp=\E[216z,
+ kund=\E[195z,
+ use=xterm,
+xterms-sun|small (80x24) xterm with sunFunctionKeys true,
+ cols#80,
+ lines#24,
+ use=xterm-sun,
+
+# This is for the extensible terminal emulator on the X11R6 contrib tape.
+emu|emu native mode,
+ mir,
+ msgr,
+ xon,
+ colors#15,
+ cols#80,
+ it#8,
+ lines#24,
+ pairs#64,
+ vt#200,
+ acsc=61a\202f\260g2j\213k\214l\215m\216n\217o\220q\222s\224t\225u\226v\227w\230x\231~\244,
+ bel=^G,
+ blink=\ES\EW,
+ bold=\ES\EU,
+ civis=\EZ,
+ clear=\EP\EE0;0;,
+ cnorm=\Ea,
+ cr=^M,
+ csr=\Ek%p1%d;%p2%d;,
+ cub=\Eq-%p1%d;,
+ cub1=^H,
+ cud=\Ep%p1%d;,
+ cud1=\EB,
+ cuf=\Eq%p1%d;,
+ cuf1=\ED,
+ cup=\EE%p1%d;%p2%d;,
+ cuu=\Ep-%p1%d;,
+ cuu1=\EA,
+ cvvis=\Ea,
+ dch=\EI%p1%d;,
+ dch1=\EI1;,
+ dl=\ER%p1%d;,
+ dl1=\ER1;,
+ ech=\Ej%p1%d;,
+ ed=\EN,
+ el=\EK,
+ el1=\EL,
+ enacs=\0,
+ home=\EE0;0;,
+ ht=^I,
+ hts=\Eh,
+ il=\EQ%p1%d;,
+ il1=\EQ1;,
+ ind=\EG,
+ is2=\ES\Er0;\Es0;,
+ kbs=^H,
+ kcub1=\EC,
+ kcud1=\EB,
+ kcuf1=\ED,
+ kcuu1=\EA,
+ kdch1=\177,
+ kent=^M,
+ kf0=\EF00,
+ kf1=\EF01,
+ kf10=\EF10,
+ kf11=\EF11,
+ kf12=\EF12,
+ kf13=\EF13,
+ kf14=\EF14,
+ kf15=\EF15,
+ kf16=\EF16,
+ kf17=\EF17,
+ kf18=\EF18,
+ kf19=\EF19,
+ kf2=\EF02,
+ kf20=\EF20,
+ kf3=\EF03,
+ kf4=\EF04,
+ kf5=\EF05,
+ kf6=\EF06,
+ kf7=\EF07,
+ kf8=\EF08,
+ kf9=\EF09,
+ kfnd=\Efind,
+ kich1=\Eins,
+ knp=\Enext,
+ kpp=\Eprior,
+ kslt=\Esel,
+ oc=\Es0;\Er0;,
+ rev=\ES\ET,
+ ri=\EF,
+ rmacs=\0,
+ rmir=\EX,
+ rmso=\ES,
+ rmul=\ES,
+ rs2=\ES\Es0;\Er0;,
+ setab=\Es%i%p1%d; setaf=\Er%i%p1%d;,
+ sgr0=\ES,
+ smacs=\0,
+ smir=\EY,
+ smso=\ES\ET,
+ smul=\ES\EV,
+ tbc=\Ej,
diff --git a/contrib/ncurses/misc/form.def b/contrib/ncurses/misc/form.def
new file mode 100644
index 000000000000..9014cf6b0441
--- /dev/null
+++ b/contrib/ncurses/misc/form.def
@@ -0,0 +1,105 @@
+LIBRARY form4 INITINSTANCE TERMINSTANCE
+DESCRIPTION "NCurses-4-2-981212, module form"
+CODE LOADONCALL
+DATA LOADONCALL NONSHARED MULTIPLE
+EXPORTS
+ "TYPE_ALNUM" @2 NONAME
+ "TYPE_ALPHA" @1 NONAME
+ "TYPE_ENUM" @3 NONAME
+ "TYPE_INTEGER" @4 NONAME
+ "TYPE_IPV4" @7 NONAME
+ "TYPE_NUMERIC" @5 NONAME
+ "TYPE_REGEXP" @6 NONAME
+ "_nc_Copy_Argument" @8 NONAME
+ "_nc_Copy_Type" @9 NONAME
+ "_nc_Default_Field" @11 NONAME
+ "_nc_Default_FieldType" @12 NONAME
+ "_nc_Default_Form" @10 NONAME
+ "_nc_First_Active_Field" @13 NONAME
+ "_nc_Free_Argument" @14 NONAME
+ "_nc_Free_Type" @15 NONAME
+ "_nc_Internal_Validation" @16 NONAME
+ "_nc_Make_Argument" @17 NONAME
+ "_nc_Position_Form_Cursor" @18 NONAME
+ "_nc_Refresh_Current_Field" @19 NONAME
+ "_nc_Set_Current_Field" @25 NONAME
+ "_nc_Set_Form_Page" @26 NONAME
+ "_nc_Synchronize_Attributes" @27 NONAME
+ "_nc_Synchronize_Options" @28 NONAME
+ "_nc_ada_getvarg" @29 NONAME
+ "_nc_ada_normalize_field_opts" @61 NONAME
+ "_nc_ada_normalize_form_opts" @62 NONAME
+ "_nc_get_field" @63 NONAME
+ "current_field" @102 NONAME
+ "data_ahead" @133 NONAME
+ "data_behind" @134 NONAME
+ "dup_field" @31 NONAME
+ "dynamic_field_info" @35 NONAME
+ "field_arg" @56 NONAME
+ "field_back" @53 NONAME
+ "field_buffer" @59 NONAME
+ "field_count" @111 NONAME
+ "field_fore" @52 NONAME
+ "field_index" @115 NONAME
+ "field_info" @34 NONAME
+ "field_init" @107 NONAME
+ "field_just" @41 NONAME
+ "field_opts" @60 NONAME
+ "field_opts_off" @51 NONAME
+ "field_opts_on" @50 NONAME
+ "field_pad" @45 NONAME
+ "field_status" @55 NONAME
+ "field_term" @108 NONAME
+ "field_type" @58 NONAME
+ "field_userptr" @57 NONAME
+ "form_driver" @126 NONAME
+ "form_fields" @101 NONAME
+ "form_init" @105 NONAME
+ "form_opts" @132 NONAME
+ "form_opts_off" @130 NONAME
+ "form_opts_on" @129 NONAME
+ "form_page" @117 NONAME
+ "form_request_by_name" @64 NONAME
+ "form_request_name" @65 NONAME
+ "form_sub" @104 NONAME
+ "form_term" @106 NONAME
+ "form_userptr" @131 NONAME
+ "form_win" @103 NONAME
+ "free_field" @33 NONAME
+ "free_fieldtype" @22 NONAME
+ "free_form" @109 NONAME
+ "link_field" @32 NONAME
+ "link_fieldtype" @21 NONAME
+ "move_field" @37 NONAME
+ "new_field" @30 NONAME
+ "new_fieldtype" @20 NONAME
+ "new_form" @100 NONAME
+ "new_page" @54 NONAME
+ "pos_form_cursor" @125 NONAME
+ "post_form" @123 NONAME
+ "scale_form" @118 NONAME
+ "set_current_field" @114 NONAME
+ "set_field_back" @43 NONAME
+ "set_field_buffer" @46 NONAME
+ "set_field_fore" @42 NONAME
+ "set_field_init" @121 NONAME
+ "set_field_just" @40 NONAME
+ "set_field_opts" @49 NONAME
+ "set_field_pad" @44 NONAME
+ "set_field_status" @47 NONAME
+ "set_field_term" @122 NONAME
+ "set_field_type" @38 NONAME
+ "set_field_userptr" @48 NONAME
+ "set_fieldtype_arg" @23 NONAME
+ "set_fieldtype_choice" @24 NONAME
+ "set_form_fields" @110 NONAME
+ "set_form_init" @119 NONAME
+ "set_form_opts" @128 NONAME
+ "set_form_page" @116 NONAME
+ "set_form_sub" @113 NONAME
+ "set_form_term" @120 NONAME
+ "set_form_userptr" @127 NONAME
+ "set_form_win" @112 NONAME
+ "set_max_field" @36 NONAME
+ "set_new_page" @39 NONAME
+ "unpost_form" @124 NONAME
diff --git a/contrib/ncurses/misc/form.ref b/contrib/ncurses/misc/form.ref
new file mode 100644
index 000000000000..18e65a680192
--- /dev/null
+++ b/contrib/ncurses/misc/form.ref
@@ -0,0 +1,106 @@
+LIBRARY FORM2 INITINSTANCE
+DESCRIPTION 'NCurses 1.9.9e-1 for OS/2 - forms library'
+EXPORTS
+;
+; SHARED VARIABLES
+;
+ "TYPE_ALPHA" @1 ;NONAME
+ "TYPE_ALNUM" @2 ;NONAME
+ "TYPE_ENUM" @3 ;NONAME
+ "TYPE_INTEGER" @4 ;NONAME
+ "TYPE_NUMERIC" @5 ;NONAME
+ "TYPE_REGEXP" @6 ;NONAME
+
+ "_nc_Default_Form" @10 ;NONAME
+ "_nc_Default_Field" @11 ;NONAME
+
+;
+; FIELD FUNCTIONS
+;
+ "new_fieldtype" @20 ;NONAME
+ "link_fieldtype" @21 ;NONAME
+
+ "free_fieldtype" @22 ;NONAME
+ "set_fieldtype_arg" @23 ;NONAME
+ "set_fieldtype_choice" @24 ;NONAME
+
+ "new_field" @30 ;NONAME
+ "dup_field" @31 ;NONAME
+ "link_field" @32 ;NONAME
+
+ "free_field" @33 ;NONAME
+ "field_info" @34 ;NONAME
+ "dynamic_field_info" @35 ;NONAME
+ "set_max_field" @36 ;NONAME
+ "move_field" @37 ;NONAME
+ "set_field_type" @38 ;NONAME
+ "set_new_page" @39 ;NONAME
+ "set_field_just" @40 ;NONAME
+ "field_just" @41 ;NONAME
+ "set_field_fore" @42 ;NONAME
+ "set_field_back" @43 ;NONAME
+ "set_field_pad" @44 ;NONAME
+ "field_pad" @45 ;NONAME
+ "set_field_buffer" @46 ;NONAME
+ "set_field_status" @47 ;NONAME
+ "set_field_userptr" @48 ;NONAME
+ "set_field_opts" @49 ;NONAME
+ "field_opts_on" @50 ;NONAME
+ "field_opts_off" @51 ;NONAME
+
+ "field_fore" @52 ;NONAME
+ "field_back" @53 ;NONAME
+
+ "new_page" @54 ;NONAME
+ "field_status" @55 ;NONAME
+ "field_arg" @56 ;NONAME
+ "field_userptr" @57 ;NONAME
+ "field_type" @58 ;NONAME
+ "field_buffer" @59 ;NONAME
+ "field_opts" @60 ;NONAME
+
+;
+; FORM FUNCTIONS
+;
+ "new_form" @100 ;NONAME
+
+ "form_fields" @101 ;NONAME
+ "current_field" @102 ;NONAME
+
+ "form_win" @103 ;NONAME
+ "form_sub" @104 ;NONAME
+
+ "form_init" @105 ;NONAME
+ "form_term" @106 ;NONAME
+ "field_init" @107 ;NONAME
+ "field_term" @108 ;NONAME
+
+ "free_form" @109 ;NONAME
+ "set_form_fields" @110 ;NONAME
+ "field_count" @111 ;NONAME
+ "set_form_win" @112 ;NONAME
+ "set_form_sub" @113 ;NONAME
+ "set_current_field" @114 ;NONAME
+ "field_index" @115 ;NONAME
+ "set_form_page" @116 ;NONAME
+ "form_page" @117 ;NONAME
+ "scale_form" @118 ;NONAME
+ "set_form_init" @119 ;NONAME
+ "set_form_term" @120 ;NONAME
+ "set_field_init" @121 ;NONAME
+ "set_field_term" @122 ;NONAME
+ "post_form" @123 ;NONAME
+ "unpost_form" @124 ;NONAME
+ "pos_form_cursor" @125 ;NONAME
+ "form_driver" @126 ;NONAME
+ "set_form_userptr" @127 ;NONAME
+ "set_form_opts" @128 ;NONAME
+ "form_opts_on" @129 ;NONAME
+ "form_opts_off" @130 ;NONAME
+
+ "form_userptr" @131 ;NONAME
+
+ "form_opts" @132 ;NONAME
+
+ "data_ahead" @133 ;NONAME
+ "data_behind" @134 ;NONAME
diff --git a/contrib/ncurses/misc/hackguide.doc b/contrib/ncurses/misc/hackguide.doc
new file mode 100644
index 000000000000..ea7a70c6f2fa
--- /dev/null
+++ b/contrib/ncurses/misc/hackguide.doc
@@ -0,0 +1,694 @@
+
+ A Hacker's Guide to NCURSES
+
+ Contents
+
+ * Abstract
+ * Objective of the Package
+ + Why System V Curses?
+ + How to Design Extensions
+ * Portability and Configuration
+ * Documentation Conventions
+ * How to Report Bugs
+ * A Tour of the Ncurses Library
+ + Library Overview
+ + The Engine Room
+ + Keyboard Input
+ + Mouse Events
+ + Output and Screen Updating
+ * The Forms and Menu Libraries
+ * A Tour of the Terminfo Compiler
+ + Translation of Non-use Capabilities
+ + Use Capability Resolution
+ + Source-Form Translation
+ * Other Utilities
+ * Style Tips for Developers
+ * Porting Hints
+
+ Abstract
+
+ This document is a hacker's tour of the ncurses library and utilities.
+ It discusses design philosophy, implementation methods, and the
+ conventions used for coding and documentation. It is recommended
+ reading for anyone who is interested in porting, extending or
+ improving the package.
+
+ Objective of the Package
+
+ The objective of the ncurses package is to provide a free software API
+ for character-cell terminals and terminal emulators with the following
+ characteristics:
+
+ * Source-compatible with historical curses implementations
+ (including the original BSD curses and System V curses.
+ * Conformant with the XSI Curses standard issued as part of XPG4 by
+ X/Open.
+ * High-quality -- stable and reliable code, wide portability, good
+ packaging, superior documentation.
+ * Featureful -- should eliminate as much of the drudgery of C
+ interface programming as possible, freeing programmers to think at
+ a higher level of design.
+
+ These objectives are in priority order. So, for example, source
+ compatibility with older version must trump featurefulness -- we
+ cannot add features if it means breaking the portion of the API
+ corresponding to historical curses versions.
+
+Why System V Curses?
+
+ We used System V curses as a model, reverse-engineering their API, in
+ order to fulfill the first two objectives.
+
+ System V curses implementations can support BSD curses programs with
+ just a recompilation, so by capturing the System V API we also capture
+ BSD's.
+
+ More importantly for the future, the XSI Curses standard issued by
+ X/Open is explicitly and closely modeled on System V. So conformance
+ with System V took us most of the way to base-level XSI conformance.
+
+How to Design Extensions
+
+ The third objective (standards conformance) requires that it be easy
+ to condition source code using ncurses so that the absence of
+ nonstandard extensions does not break the code.
+
+ Accordingly, we have a policy of associating with each nonstandard
+ extension a feature macro, so that ncurses client code can use this
+ macro to condition in or out the code that requires the ncurses
+ extension.
+
+ For example, there is a macro NCURSES_MOUSE_VERSION which XSI Curses
+ does not define, but which is defined in the ncurses library header.
+ You can use this to condition the calls to the mouse API calls.
+
+ Portability and Configuration
+
+ Code written for ncurses may assume an ANSI-standard C compiler and
+ POSIX-compatible OS interface. It may also assume the presence of a
+ System-V-compatible select(2) call.
+
+ We encourage (but do not require) developers to make the code friendly
+ to less-capable UNIX environments wherever possible.
+
+ We encourage developers to support OS-specific optimizations and
+ methods not available under POSIX/ANSI, provided only that:
+
+ * All such code is properly conditioned so the build process does
+ not attempt to compile it under a plain ANSI/POSIX environment.
+ * Adding such implementation methods does not introduce
+ incompatibilities in the ncurses API between platforms.
+
+ We use GNU autoconf(1) as a tool to deal with portability issues. The
+ right way to leverage an OS-specific feature is to modify the autoconf
+ specification files (configure.in and aclocal.m4) to set up a new
+ feature macro, which you then use to condition your code.
+
+ Documentation Conventions
+
+ There are three kinds of documentation associated with this package.
+ Each has a different preferred format:
+
+ * Package-internal files (README, INSTALL, TO-DO etc.)
+ * Manual pages.
+ * Everything else (i.e., narrative documentation).
+
+ Our conventions are simple:
+
+ 1. Maintain package-internal files in plain text. The expected viewer
+ for them more(1) or an editor window; there's no point in
+ elaborate mark-up.
+ 2. Mark up manual pages in the man macros. These have to be viewable
+ through traditional man(1) programs.
+ 3. Write everything else in HTML.
+
+ When in doubt, HTMLize a master and use lynx(1) to generate plain
+ ASCII (as we do for the announcement document).
+
+ The reason for choosing HTML is that it's (a) well-adapted for on-line
+ browsing through viewers that are everywhere; (b) more easily readable
+ as plain text than most other mark-ups, if you don't have a viewer;
+ and (c) carries enough information that you can generate a
+ nice-looking printed version from it. Also, of course, it make
+ exporting things like the announcement document to WWW pretty trivial.
+
+ How to Report Bugs
+
+ The reporting address for bugs is bug-ncurses@gnu.org. This is a
+ majordomo list; to join, write to bug-ncurses-request@gnu.org with a
+ message containing the line:
+ subscribe <name>@<host.domain>
+
+ The ncurses code is maintained by a small group of volunteers. While
+ we try our best to fix bugs promptly, we simply don't have a lot of
+ hours to spend on elementary hand-holding. We rely on intelligent
+ cooperation from our users. If you think you have found a bug in
+ ncurses, there are some steps you can take before contacting us that
+ will help get the bug fixed quickly.
+
+ In order to use our bug-fixing time efficiently, we put people who
+ show us they've taken these steps at the head of our queue. This means
+ that if you don't, you'll probably end up at the tail end and have to
+ wait a while.
+
+ 1. Develop a recipe to reproduce the bug.
+ Bugs we can reproduce are likely to be fixed very quickly, often
+ within days. The most effective single thing you can do to get a
+ quick fix is develop a way we can duplicate the bad behavior --
+ ideally, by giving us source for a small, portable test program
+ that breaks the library. (Even better is a keystroke recipe using
+ one of the test programs provided with the distribution.)
+ 2. Try to reproduce the bug on a different terminal type.
+ In our experience, most of the behaviors people report as library
+ bugs are actually due to subtle problems in terminal descriptions.
+ This is especially likely to be true if you're using a traditional
+ asynchronous terminal or PC-based terminal emulator, rather than
+ xterm or a UNIX console entry.
+ It's therefore extremely helpful if you can tell us whether or not
+ your problem reproduces on other terminal types. Usually you'll
+ have both a console type and xterm available; please tell us
+ whether or not your bug reproduces on both.
+ If you have xterm available, it is also good to collect xterm
+ reports for different window sizes. This is especially true if you
+ normally use an unusual xterm window size -- a surprising number
+ of the bugs we've seen are either triggered or masked by these.
+ 3. Generate and examine a trace file for the broken behavior.
+ Recompile your program with the debugging versions of the
+ libraries. Insert a trace() call with the argument set to
+ TRACE_UPDATE. (See "Writing Programs with NCURSES" for details on
+ trace levels.) Reproduce your bug, then look at the trace file to
+ see what the library was actually doing.
+ Another frequent cause of apparent bugs is application coding
+ errors that cause the wrong things to be put on the virtual
+ screen. Looking at the virtual-screen dumps in the trace file will
+ tell you immediately if this is happening, and save you from the
+ possible embarrassment of being told that the bug is in your code
+ and is your problem rather than ours.
+ If the virtual-screen dumps look correct but the bug persists,
+ it's possible to crank up the trace level to give more and more
+ information about the library's update actions and the control
+ sequences it issues to perform them. The test directory of the
+ distribution contains a tool for digesting these logs to make them
+ less tedious to wade through.
+ Often you'll find terminfo problems at this stage by noticing that
+ the escape sequences put out for various capabilities are wrong.
+ If not, you're likely to learn enough to be able to characterize
+ any bug in the screen-update logic quite exactly.
+ 4. Report details and symptoms, not just interpretations.
+ If you do the preceding two steps, it is very likely that you'll
+ discover the nature of the problem yourself and be able to send us
+ a fix. This will create happy feelings all around and earn you
+ good karma for the first time you run into a bug you really can't
+ characterize and fix yourself.
+ If you're still stuck, at least you'll know what to tell us.
+ Remember, we need details. If you guess about what is safe to
+ leave out, you are too likely to be wrong.
+ If your bug produces a bad update, include a trace file. Try to
+ make the trace at the least voluminous level that pins down the
+ bug. Logs that have been through tracemunch are OK, it doesn't
+ throw away any information (actually they're better than
+ un-munched ones because they're easier to read).
+ If your bug produces a core-dump, please include a symbolic stack
+ trace generated by gdb(1) or your local equivalent.
+ Tell us about every terminal on which you've reproduced the bug --
+ and every terminal on which you can't. Ideally, sent us terminfo
+ sources for all of these (yours might differ from ours).
+ Include your ncurses version and your OS/machine type, of course!
+ You can find your ncurses version in the curses.h file.
+
+ If your problem smells like a logic error or in cursor movement or
+ scrolling or a bad capability, there are a couple of tiny test frames
+ for the library algorithms in the progs directory that may help you
+ isolate it. These are not part of the normal build, but do have their
+ own make productions.
+
+ The most important of these is mvcur, a test frame for the
+ cursor-movement optimization code. With this program, you can see
+ directly what control sequences will be emitted for any given cursor
+ movement or scroll/insert/delete operations. If you think you've got a
+ bad capability identified, you can disable it and test again. The
+ program is command-driven and has on-line help.
+
+ If you think the vertical-scroll optimization is broken, or just want
+ to understand how it works better, build hashmap and read the header
+ comments of hardscroll.c and hashmap.c; then try it out. You can also
+ test the hardware-scrolling optimization separately with hardscroll.
+
+ There's one other interactive tester, tctest, that exercises
+ translation between termcap and terminfo formats. If you have a
+ serious need to run this, you probably belong on our development team!
+
+ A Tour of the Ncurses Library
+
+Library Overview
+
+ Most of the library is superstructure -- fairly trivial convenience
+ interfaces to a small set of basic functions and data structures used
+ to manipulate the virtual screen (in particular, none of this code
+ does any I/O except through calls to more fundamental modules
+ described below). The files
+
+ lib_addch.c lib_bkgd.c lib_box.c lib_chgat.c lib_clear.c
+ lib_clearok.c lib_clrbot.c lib_clreol.c lib_colorset.c lib_data.c
+ lib_delch.c lib_delwin.c lib_echo.c lib_erase.c lib_gen.c
+ lib_getstr.c lib_hline.c lib_immedok.c lib_inchstr.c lib_insch.c
+ lib_insdel.c lib_insstr.c lib_instr.c lib_isendwin.c lib_keyname.c
+ lib_leaveok.c lib_move.c lib_mvwin.c lib_overlay.c lib_pad.c
+ lib_printw.c lib_redrawln.c lib_scanw.c lib_screen.c lib_scroll.c
+ lib_scrollok.c lib_scrreg.c lib_set_term.c lib_slk.c
+ lib_slkatr_set.c lib_slkatrof.c lib_slkatron.c lib_slkatrset.c
+ lib_slkattr.c lib_slkclear.c lib_slkcolor.c lib_slkinit.c
+ lib_slklab.c lib_slkrefr.c lib_slkset.c lib_slktouch.c lib_touch.c
+ lib_unctrl.c lib_vline.c lib_wattroff.c lib_wattron.c lib_window.c
+
+ are all in this category. They are very unlikely to need change,
+ barring bugs or some fundamental reorganization in the underlying data
+ structures.
+
+ These files are used only for debugging support:
+
+ lib_trace.c lib_traceatr.c lib_tracebits.c lib_tracechr.c
+ lib_tracedmp.c lib_tracemse.c trace_buf.c
+
+ It is rather unlikely you will ever need to change these, unless you
+ want to introduce a new debug trace level for some reasoon.
+
+ There is another group of files that do direct I/O via tputs(),
+ computations on the terminal capabilities, or queries to the OS
+ environment, but nevertheless have only fairly low complexity. These
+ include:
+
+ lib_acs.c lib_beep.c lib_color.c lib_endwin.c lib_initscr.c
+ lib_longname.c lib_newterm.c lib_options.c lib_termcap.c lib_ti.c
+ lib_tparm.c lib_tputs.c lib_vidattr.c read_entry.c.
+
+ They are likely to need revision only if ncurses is being ported to an
+ environment without an underlying terminfo capability representation.
+
+ These files have serious hooks into the tty driver and signal
+ facilities:
+
+ lib_kernel.c lib_baudrate.c lib_raw.c lib_tstp.c lib_twait.c
+
+ If you run into porting snafus moving the package to another UNIX, the
+ problem is likely to be in one of these files. The file lib_print.c
+ uses sleep(2) and also falls in this category.
+
+ Almost all of the real work is done in the files
+
+ hardscroll.c hashmap.c lib_addch.c lib_doupdate.c lib_getch.c
+ lib_mouse.c lib_mvcur.c lib_refresh.c lib_setup.c lib_vidattr.c
+
+ Most of the algorithmic complexity in the library lives in these
+ files. If there is a real bug in ncurses itself, it's probably here.
+ We'll tour some of these files in detail below (see The Engine Room).
+
+ Finally, there is a group of files that is actually most of the
+ terminfo compiler. The reason this code lives in the ncurses library
+ is to support fallback to /etc/termcap. These files include
+
+ alloc_entry.c captoinfo.c comp_captab.c comp_error.c comp_hash.c
+ comp_parse.c comp_scan.c parse_entry.c read_termcap.c write_entry.c
+
+ We'll discuss these in the compiler tour.
+
+The Engine Room
+
+ Keyboard Input
+
+ All ncurses input funnels through the function wgetch(), defined in
+ lib_getch.c. This function is tricky; it has to poll for keyboard and
+ mouse events and do a running match of incoming input against the set
+ of defined special keys.
+
+ The central data structure in this module is a FIFO queue, used to
+ match multiple-character input sequences against special-key
+ capabilities; also to implement pushback via ungetch().
+
+ The wgetch() code distinguishes between function key sequences and the
+ same sequences typed manually by doing a timed wait after each input
+ character that could lead a function key sequence. If the entire
+ sequence takes less than 1 second, it is assumed to have been
+ generated by a function key press.
+
+ Hackers bruised by previous encounters with variant select(2) calls
+ may find the code in lib_twait.c interesting. It deals with the
+ problem that some BSD selects don't return a reliable time-left value.
+ The function timed_wait() effectively simulates a System V select.
+
+ Mouse Events
+
+ If the mouse interface is active, wgetch() polls for mouse events each
+ call, before it goes to the keyboard for input. It is up to
+ lib_mouse.c how the polling is accomplished; it may vary for different
+ devices.
+
+ Under xterm, however, mouse event notifications come in via the
+ keyboard input stream. They are recognized by having the kmous
+ capability as a prefix. This is kind of klugey, but trying to wire in
+ recognition of a mouse key prefix without going through the
+ function-key machinery would be just too painful, and this turns out
+ to imply having the prefix somewhere in the function-key capabilities
+ at terminal-type initialization.
+
+ This kluge only works because kmous isn't actually used by any
+ historic terminal type or curses implementation we know of. Best guess
+ is it's a relic of some forgotten experiment in-house at Bell Labs
+ that didn't leave any traces in the publicly-distributed System V
+ terminfo files. If System V or XPG4 ever gets serious about using it
+ again, this kluge may have to change.
+
+ Here are some more details about mouse event handling:
+
+ The lib_mouse()code is logically split into a lower level that accepts
+ event reports in a device-dependent format and an upper level that
+ parses mouse gestures and filters events. The mediating data structure
+ is a circular queue of event structures.
+
+ Functionally, the lower level's job is to pick up primitive events and
+ put them on the circular queue. This can happen in one of two ways:
+ either (a) _nc_mouse_event() detects a series of incoming mouse
+ reports and queues them, or (b) code in lib_getch.c detects the kmous
+ prefix in the keyboard input stream and calls _nc_mouse_inline to
+ queue up a series of adjacent mouse reports.
+
+ In either case, _nc_mouse_parse() should be called after the series is
+ accepted to parse the digested mouse reports (low-level events) into a
+ gesture (a high-level or composite event).
+
+ Output and Screen Updating
+
+ With the single exception of character echoes during a wgetnstr() call
+ (which simulates cooked-mode line editing in an ncurses window), the
+ library normally does all its output at refresh time.
+
+ The main job is to go from the current state of the screen (as
+ represented in the curscr window structure) to the desired new state
+ (as represented in the newscr window structure), while doing as little
+ I/O as possible.
+
+ The brains of this operation are the modules hashmap.c, hardscroll.c
+ and lib_doupdate.c; the latter two use lib_mvcur.c. Essentially, what
+ happens looks like this:
+
+ The hashmap.c module tries to detect vertical motion changes between
+ the real and virtual screens. This information is represented by the
+ oldindex members in the newscr structure. These are modified by
+ vertical-motion and clear operations, and both are re-initialized
+ after each update. To this change-journalling information, the hashmap
+ code adds deductions made using a modified Heckel algorithm on hash
+ values generated from the line contents.
+
+ The hardscroll.c module computes an optimum set of scroll, insertion,
+ and deletion operations to make the indices match. It calls
+ _nc_mvcur_scrolln() in lib_mvcur.c to do those motions.
+
+ Then lib_doupdate.c goes to work. Its job is to do line-by-line
+ transformations of curscr lines to newscr lines. Its main tool is the
+ routine mvcur() in lib_mvcur.c. This routine does cursor-movement
+ optimization, attempting to get from given screen location A to given
+ location B in the fewest output characters posible.
+
+ If you want to work on screen optimizations, you should use the fact
+ that (in the trace-enabled version of the library) enabling the
+ TRACE_TIMES trace level causes a report to be emitted after each
+ screen update giving the elapsed time and a count of characters
+ emitted during the update. You can use this to tell when an update
+ optimization improves efficiency.
+
+ In the trace-enabled version of the library, it is also possible to
+ disable and re-enable various optimizations at runtime by tweaking the
+ variable _nc_optimize_enable. See the file include/curses.h.in for
+ mask values, near the end.
+
+ The Forms and Menu Libraries
+
+ The forms and menu libraries should work reliably in any environment
+ you can port ncurses to. The only portability issue anywhere in them
+ is what flavor of regular expressions the built-in form field type
+ TYPE_REGEXP will recognize.
+
+ The configuration code prefers the POSIX regex facility, modeled on
+ System V's, but will settle for BSD regexps if the former isn't
+ available.
+
+ Historical note: the panels code was written primarily to assist in
+ porting u386mon 2.0 (comp.sources.misc v14i001-4) to systems lacking
+ panels support; u386mon 2.10 and beyond use it. This version has been
+ slightly cleaned up for ncurses.
+
+ A Tour of the Terminfo Compiler
+
+ The ncurses implementation of tic is rather complex internally; it has
+ to do a trying combination of missions. This starts with the fact
+ that, in addition to its normal duty of compiling terminfo sources
+ into loadable terminfo binaries, it has to be able to handle termcap
+ syntax and compile that too into terminfo entries.
+
+ The implementation therefore starts with a table-driven, dual-mode
+ lexical analyzer (in comp_scan.c). The lexer chooses its mode (termcap
+ or terminfo) based on the first `,' or `:' it finds in each entry. The
+ lexer does all the work of recognizing capability names and values;
+ the grammar above it is trivial, just "parse entries till you run out
+ of file".
+
+Translation of Non-use Capabilities
+
+ Translation of most things besides use capabilities is pretty
+ straightforward. The lexical analyzer's tokenizer hands each
+ capability name to a hash function, which drives a table lookup. The
+ table entry yields an index which is used to look up the token type in
+ another table, and controls interpretation of the value.
+
+ One possibly interesting aspect of the implementation is the way the
+ compiler tables are initialized. All the tables are generated by
+ various awk/sed/sh scripts from a master table include/Caps; these
+ scripts actually write C initializers which are linked to the
+ compiler. Furthermore, the hash table is generated in the same way, so
+ it doesn't have to be generated at compiler startup time (another
+ benefit of this organization is that the hash table can be in
+ shareable text space).
+
+ Thus, adding a new capability is usually pretty trivial, just a matter
+ of adding one line to the include/Caps file. We'll have more to say
+ about this in the section on Source-Form Translation.
+
+Use Capability Resolution
+
+ The background problem that makes tic tricky isn't the capability
+ translation itself, it's the resolution of use capabilities. Older
+ versions would not handle forward use references for this reason (that
+ is, a using terminal always had to follow its use target in the source
+ file). By doing this, they got away with a simple implementation
+ tactic; compile everything as it blows by, then resolve uses from
+ compiled entries.
+
+ This won't do for ncurses. The problem is that that the whole
+ compilation process has to be embeddable in the ncurses library so
+ that it can be called by the startup code to translate termcap entries
+ on the fly. The embedded version can't go promiscuously writing
+ everything it translates out to disk -- for one thing, it will
+ typically be running with non-root permissions.
+
+ So our tic is designed to parse an entire terminfo file into a
+ doubly-linked circular list of entry structures in-core, and then do
+ use resolution in-memory before writing everything out. This design
+ has other advantages: it makes forward and back use-references equally
+ easy (so we get the latter for free), and it makes checking for name
+ collisions before they're written out easy to do.
+
+ And this is exactly how the embedded version works. But the
+ stand-alone user-accessible version of tic partly reverts to the
+ historical strategy; it writes to disk (not keeping in core) any entry
+ with no use references.
+
+ This is strictly a core-economy kluge, implemented because the
+ terminfo master file is large enough that some core-poor systems swap
+ like crazy when you compile it all in memory...there have been reports
+ of this process taking three hours, rather than the twenty seconds or
+ less typical on the author's development box.
+
+ So. The executable tic passes the entry-parser a hook that immediately
+ writes out the referenced entry if it has no use capabilities. The
+ compiler main loop refrains from adding the entry to the in-core list
+ when this hook fires. If some other entry later needs to reference an
+ entry that got written immediately, that's OK; the resolution code
+ will fetch it off disk when it can't find it in core.
+
+ Name collisions will still be detected, just not as cleanly. The
+ write_entry() code complains before overwriting an entry that
+ postdates the time of tic's first call to write_entry(), Thus it will
+ complain about overwriting entries newly made during the tic run, but
+ not about overwriting ones that predate it.
+
+Source-Form Translation
+
+ Another use of tic is to do source translation between various termcap
+ and terminfo formats. There are more variants out there than you might
+ think; the ones we know about are described in the captoinfo(1) manual
+ page.
+
+ The translation output code (dump_entry() in ncurses/dump_entry.c) is
+ shared with the infocmp(1) utility. It takes the same internal
+ representation used to generate the binary form and dumps it to
+ standard output in a specified format.
+
+ The include/Caps file has a header comment describing ways you can
+ specify source translations for nonstandard capabilities just by
+ altering the master table. It's possible to set up capability aliasing
+ or tell the compiler to plain ignore a given capability without
+ writing any C code at all.
+
+ For circumstances where you need to do algorithmic translation, there
+ are functions in parse_entry.c called after the parse of each entry
+ that are specifically intended to encapsulate such translations. This,
+ for example, is where the AIX box1 capability get translated to an
+ acsc string.
+
+ Other Utilities
+
+ The infocmp utility is just a wrapper around the same entry-dumping
+ code used by tic for source translation. Perhaps the one interesting
+ aspect of the code is the use of a predicate function passed in to
+ dump_entry() to control which capabilities are dumped. This is
+ necessary in order to handle both the ordinary De-compilation case and
+ entry difference reporting.
+
+ The tput and clear utilities just do an entry load followed by a
+ tputs() of a selected capability.
+
+ Style Tips for Developers
+
+ See the TO-DO file in the top-level directory of the source
+ distribution for additions that would be particularly useful.
+
+ The prefix _nc_ should be used on library public functions that are
+ not part of the curses API in order to prevent pollution of the
+ application namespace. If you have to add to or modify the function
+ prototypes in curses.h.in, read ncurses/MKlib_gen.sh first so you can
+ avoid breaking XSI conformance. Please join the ncurses mailing list.
+ See the INSTALL file in the top level of the distribution for details
+ on the list.
+
+ Look for the string FIXME in source files to tag minor bugs and
+ potential problems that could use fixing.
+
+ Don't try to auto-detect OS features in the main body of the C code.
+ That's the job of the configuration system.
+
+ To hold down complexity, do make your code data-driven. Especially, if
+ you can drive logic from a table filtered out of include/Caps, do it.
+ If you find you need to augment the data in that file in order to
+ generate the proper table, that's still preferable to ad-hoc code --
+ that's why the fifth field (flags) is there.
+
+ Have fun!
+
+ Porting Hints
+
+ The following notes are intended to be a first step towards DOS and
+ Macintosh ports of the ncurses libraries.
+
+ The following library modules are `pure curses'; they operate only on
+ the curses internal structures, do all output through other curses
+ calls (not including tputs() and putp()) and do not call any other
+ UNIX routines such as signal(2) or the stdio library. Thus, they
+ should not need to be modified for single-terminal ports.
+
+ lib_addch.c lib_addstr.c lib_bkgd.c lib_box.c lib_clear.c
+ lib_clrbot.c lib_clreol.c lib_delch.c lib_delwin.c lib_erase.c
+ lib_inchstr.c lib_insch.c lib_insdel.c lib_insstr.c lib_keyname.c
+ lib_move.c lib_mvwin.c lib_newwin.c lib_overlay.c lib_pad.c
+ lib_printw.c lib_refresh.c lib_scanw.c lib_scroll.c lib_scrreg.c
+ lib_set_term.c lib_touch.c lib_tparm.c lib_tputs.c lib_unctrl.c
+ lib_window.c panel.c
+
+ This module is pure curses, but calls outstr():
+
+ lib_getstr.c
+
+ These modules are pure curses, except that they use tputs() and
+ putp():
+
+ lib_beep.c lib_color.c lib_endwin.c lib_options.c lib_slk.c
+ lib_vidattr.c
+
+ This modules assist in POSIX emulation on non-POSIX systems:
+
+ sigaction.c
+ signal calls
+
+ The following source files will not be needed for a
+ single-terminal-type port.
+
+ alloc_entry.c captoinfo.c clear.c comp_captab.c comp_error.c
+ comp_hash.c comp_main.c comp_parse.c comp_scan.c dump_entry.c
+ infocmp.c parse_entry.c read_entry.c tput.c write_entry.c
+
+ The following modules will use open()/read()/write()/close()/lseek()
+ on files, but no other OS calls.
+
+ lib_screen.c
+ used to read/write screen dumps
+
+ lib_trace.c
+ used to write trace data to the logfile
+
+ Modules that would have to be modified for a port start here:
+
+ The following modules are `pure curses' but contain assumptions
+ inappropriate for a memory-mapped port.
+
+ lib_longname.c
+ assumes there may be multiple terminals
+
+ lib_acs.c
+ assumes acs_map as a double indirection
+
+ lib_mvcur.c
+ assumes cursor moves have variable cost
+
+ lib_termcap.c
+ assumes there may be multiple terminals
+
+ lib_ti.c
+ assumes there may be multiple terminals
+
+ The following modules use UNIX-specific calls:
+
+ lib_doupdate.c
+ input checking
+
+ lib_getch.c
+ read()
+
+ lib_initscr.c
+ getenv()
+
+ lib_newterm.c
+
+ lib_baudrate.c
+
+ lib_kernel.c
+ various tty-manipulation and system calls
+
+ lib_raw.c
+ various tty-manipulation calls
+
+ lib_setup.c
+ various tty-manipulation calls
+
+ lib_restart.c
+ various tty-manipulation calls
+
+ lib_tstp.c
+ signal-manipulation calls
+
+ lib_twait.c
+ gettimeofday(), select().
+ _________________________________________________________________
+
+
+ Eric S. Raymond <esr@snark.thyrsus.com>
+
+ (Note: This is not the bug address!)
diff --git a/contrib/ncurses/misc/hackguide.html b/contrib/ncurses/misc/hackguide.html
new file mode 100644
index 000000000000..417399a68365
--- /dev/null
+++ b/contrib/ncurses/misc/hackguide.html
@@ -0,0 +1,883 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
+<!--
+ $Id: hackguide.html,v 1.23 1999/01/17 00:15:48 tom Exp $
+-->
+<HTML>
+<HEAD>
+<TITLE>A Hacker's Guide to Ncurses Internals</TITLE>
+<link rev="made" href="mailto:bugs-ncurses@gnu.org">
+<!--
+This document is self-contained, *except* that there is one relative link to
+the ncurses-intro.html document, expected to be in the same directory with
+this one.
+-->
+</HEAD>
+<BODY>
+
+<H1>A Hacker's Guide to NCURSES</H1>
+
+<H1>Contents</H1>
+<UL>
+<LI><A HREF="#abstract">Abstract</A>
+<P>
+<LI><A HREF="#objective">Objective of the Package</A>
+<UL>
+<LI><A HREF="#whysvr4">Why System V Curses?</A>
+<LI><A HREF="#extensions">How to Design Extensions</A>
+</UL>
+<LI><A HREF="#portability">Portability and Configuration</A><UL>
+</UL>
+<LI><A HREF="#documentation">Documentation Conventions</A>
+<P>
+<LI><A HREF="#bugtrack">How to Report Bugs</A>
+<P>
+<LI><A HREF="#ncurslib">A Tour of the Ncurses Library</A>
+<UL>
+<LI><A HREF="#loverview">Library Overview</A>
+<LI><A HREF="#engine">The Engine Room</A>
+<LI><A HREF="#input">Keyboard Input</A>
+<LI><A HREF="#mouse">Mouse Events</A>
+<LI><A HREF="#output">Output and Screen Updating</A>
+</UL>
+<LI><A HREF="#fmnote">The Forms and Menu Libraries</A>
+<P>
+<LI><A HREF="#tic">A Tour of the Terminfo Compiler</A>
+<UL>
+<LI><A HREF="#nonuse">Translation of Non-<STRONG>use</STRONG> Capabilities</A>
+<LI><A HREF="#uses">Use Capability Resolution</A>
+<LI><A HREF="#translation">Source-Form Translation</A>
+</UL>
+<LI><A HREF="#utils">Other Utilities</A>
+<P>
+<LI><A HREF="#style">Style Tips for Developers</A>
+<P>
+<LI><A HREF="#port">Porting Hints</A>
+</UL>
+
+<H1><A NAME="abstract">Abstract</A></H1>
+
+This document is a hacker's tour of the <STRONG>ncurses</STRONG> library and utilities.
+It discusses design philosophy, implementation methods, and the
+conventions used for coding and documentation. It is recommended
+reading for anyone who is interested in porting, extending or improving the
+package. <P>
+
+<H1><A NAME="objective">Objective of the Package</A></H1>
+
+The objective of the <STRONG>ncurses</STRONG> package is to provide a free software API for
+character-cell terminals and terminal emulators with the following
+characteristics: <P>
+
+<UL>
+<LI>Source-compatible with historical curses implementations (including
+ the original BSD curses and System V curses.
+<P>
+<LI>Conformant with the XSI Curses standard issued as part of XPG4 by
+ X/Open.
+<P>
+<LI>High-quality -- stable and reliable code, wide portability, good
+ packaging, superior documentation.
+<P>
+<LI>Featureful -- should eliminate as much of the drudgery of C interface
+ programming as possible, freeing programmers to think at a higher
+ level of design.
+</UL>
+
+These objectives are in priority order. So, for example, source
+compatibility with older version must trump featurefulness -- we cannot
+add features if it means breaking the portion of the API corresponding
+to historical curses versions. <P>
+
+<H2><A NAME="whysvr4">Why System V Curses?</A></H2>
+
+We used System V curses as a model, reverse-engineering their API, in
+order to fulfill the first two objectives. <P>
+
+System V curses implementations can support BSD curses programs with
+just a recompilation, so by capturing the System V API we also
+capture BSD's. <P>
+
+More importantly for the future, the XSI Curses standard issued by X/Open
+is explicitly and closely modeled on System V. So conformance with
+System V took us most of the way to base-level XSI conformance. <P>
+
+<H2><A NAME="extensions">How to Design Extensions</A></H2>
+
+The third objective (standards conformance) requires that it be easy to
+condition source code using <STRONG>ncurses</STRONG> so that the absence of nonstandard
+extensions does not break the code. <P>
+
+Accordingly, we have a policy of associating with each nonstandard extension
+a feature macro, so that ncurses client code can use this macro to condition
+in or out the code that requires the <STRONG>ncurses</STRONG> extension. <P>
+
+For example, there is a macro <CODE>NCURSES_MOUSE_VERSION</CODE> which XSI Curses
+does not define, but which is defined in the <STRONG>ncurses</STRONG> library header.
+You can use this to condition the calls to the mouse API calls. <P>
+
+<H1><A NAME="portability">Portability and Configuration</A></H1>
+
+Code written for <STRONG>ncurses</STRONG> may assume an ANSI-standard C compiler and
+POSIX-compatible OS interface. It may also assume the presence of a
+System-V-compatible <EM>select(2)</EM> call. <P>
+
+We encourage (but do not require) developers to make the code friendly
+to less-capable UNIX environments wherever possible. <P>
+
+We encourage developers to support OS-specific optimizations and methods
+not available under POSIX/ANSI, provided only that: <P>
+
+<UL>
+<LI>All such code is properly conditioned so the build process does not
+ attempt to compile it under a plain ANSI/POSIX environment.
+<P>
+<LI>Adding such implementation methods does not introduce incompatibilities
+ in the <STRONG>ncurses</STRONG> API between platforms.
+</UL>
+
+We use GNU <CODE>autoconf(1)</CODE> as a tool to deal with portability issues.
+The right way to leverage an OS-specific feature is to modify the autoconf
+specification files (configure.in and aclocal.m4) to set up a new feature
+macro, which you then use to condition your code. <P>
+
+<H1><A NAME="documentation">Documentation Conventions</A></H1>
+
+There are three kinds of documentation associated with this package. Each
+has a different preferred format: <P>
+
+<UL>
+<LI>Package-internal files (README, INSTALL, TO-DO etc.)
+<LI>Manual pages.
+<LI>Everything else (i.e., narrative documentation).
+</UL>
+
+Our conventions are simple: <P>
+<OL>
+<LI><STRONG>Maintain package-internal files in plain text.</STRONG>
+ The expected viewer for them <EM>more(1)</EM> or an editor window; there's
+ no point in elaborate mark-up. <P>
+
+<LI><STRONG>Mark up manual pages in the man macros.</STRONG> These have to be viewable
+ through traditional <EM>man(1)</EM> programs. <P>
+
+<LI><STRONG>Write everything else in HTML.</STRONG>
+</OL>
+
+When in doubt, HTMLize a master and use <EM>lynx(1)</EM> to generate
+plain ASCII (as we do for the announcement document). <P>
+
+The reason for choosing HTML is that it's (a) well-adapted for on-line
+browsing through viewers that are everywhere; (b) more easily readable
+as plain text than most other mark-ups, if you don't have a viewer; and (c)
+carries enough information that you can generate a nice-looking printed
+version from it. Also, of course, it make exporting things like the
+announcement document to WWW pretty trivial.<P>
+
+<H1><A NAME="bugtrack">How to Report Bugs</A></H1>
+
+The <A NAME="bugreport">reporting address for bugs</A> is
+<A HREF="mailto:bug-ncurses@gnu.org">bug-ncurses@gnu.org</A>.
+This is a majordomo list; to join, write
+to <CODE>bug-ncurses-request@gnu.org</CODE> with a message containing the line:
+<PRE>
+ subscribe &lt;name&gt;@&lt;host.domain&gt;
+</PRE>
+
+The <CODE>ncurses</CODE> code is maintained by a small group of
+volunteers. While we try our best to fix bugs promptly, we simply
+don't have a lot of hours to spend on elementary hand-holding. We rely
+on intelligent cooperation from our users. If you think you have
+found a bug in <CODE>ncurses</CODE>, there are some steps you can take
+before contacting us that will help get the bug fixed quickly. <P>
+
+In order to use our bug-fixing time efficiently, we put people who
+show us they've taken these steps at the head of our queue. This
+means that if you don't, you'll probably end up at the tail end and
+have to wait a while. <P>
+
+<OL>
+<LI>Develop a recipe to reproduce the bug. <P>
+
+Bugs we can reproduce are likely to be fixed very quickly, often
+within days. The most effective single thing you can do to get a
+quick fix is develop a way we can duplicate the bad behavior --
+ideally, by giving us source for a small, portable test program that
+breaks the library. (Even better is a keystroke recipe using one of
+the test programs provided with the distribution.) <P>
+
+<LI>Try to reproduce the bug on a different terminal type. <P>
+
+In our experience, most of the behaviors people report as library bugs
+are actually due to subtle problems in terminal descriptions. This is
+especially likely to be true if you're using a traditional
+asynchronous terminal or PC-based terminal emulator, rather than xterm
+or a UNIX console entry. <P>
+
+It's therefore extremely helpful if you can tell us whether or not your
+problem reproduces on other terminal types. Usually you'll have both
+a console type and xterm available; please tell us whether or not your
+bug reproduces on both. <P>
+
+If you have xterm available, it is also good to collect xterm reports for
+different window sizes. This is especially true if you normally use an
+unusual xterm window size -- a surprising number of the bugs we've seen
+are either triggered or masked by these. <P>
+
+<LI>Generate and examine a trace file for the broken behavior. <P>
+
+Recompile your program with the debugging versions of the libraries.
+Insert a <CODE>trace()</CODE> call with the argument set to <CODE>TRACE_UPDATE</CODE>.
+(See <A HREF="ncurses-intro.html#debugging">"Writing Programs with
+NCURSES"</A> for details on trace levels.)
+Reproduce your bug, then look at the trace file to see what the library
+was actually doing. <P>
+
+Another frequent cause of apparent bugs is application coding errors
+that cause the wrong things to be put on the virtual screen. Looking
+at the virtual-screen dumps in the trace file will tell you immediately if
+this is happening, and save you from the possible embarrassment of being
+told that the bug is in your code and is your problem rather than ours. <P>
+
+If the virtual-screen dumps look correct but the bug persists, it's
+possible to crank up the trace level to give more and more information
+about the library's update actions and the control sequences it issues
+to perform them. The test directory of the distribution contains a
+tool for digesting these logs to make them less tedious to wade
+through. <P>
+
+Often you'll find terminfo problems at this stage by noticing that the
+escape sequences put out for various capabilities are wrong. If not,
+you're likely to learn enough to be able to characterize any bug in
+the screen-update logic quite exactly. <P>
+
+<LI>Report details and symptoms, not just interpretations. <P>
+
+If you do the preceding two steps, it is very likely that you'll discover
+the nature of the problem yourself and be able to send us a fix. This
+will create happy feelings all around and earn you good karma for the first
+time you run into a bug you really can't characterize and fix yourself. <P>
+
+If you're still stuck, at least you'll know what to tell us. Remember, we
+need details. If you guess about what is safe to leave out, you are too
+likely to be wrong. <P>
+
+If your bug produces a bad update, include a trace file. Try to make
+the trace at the <EM>least</EM> voluminous level that pins down the
+bug. Logs that have been through tracemunch are OK, it doesn't throw
+away any information (actually they're better than un-munched ones because
+they're easier to read). <P>
+
+If your bug produces a core-dump, please include a symbolic stack trace
+generated by gdb(1) or your local equivalent. <P>
+
+Tell us about every terminal on which you've reproduced the bug -- and
+every terminal on which you can't. Ideally, sent us terminfo sources
+for all of these (yours might differ from ours). <P>
+
+Include your ncurses version and your OS/machine type, of course! You can
+find your ncurses version in the <CODE>curses.h</CODE> file.
+</OL>
+
+If your problem smells like a logic error or in cursor movement or
+scrolling or a bad capability, there are a couple of tiny test frames
+for the library algorithms in the progs directory that may help you
+isolate it. These are not part of the normal build, but do have their
+own make productions. <P>
+
+The most important of these is <CODE>mvcur</CODE>, a test frame for the
+cursor-movement optimization code. With this program, you can see
+directly what control sequences will be emitted for any given cursor
+movement or scroll/insert/delete operations. If you think you've got
+a bad capability identified, you can disable it and test again. The
+program is command-driven and has on-line help. <P>
+
+If you think the vertical-scroll optimization is broken, or just want to
+understand how it works better, build <CODE>hashmap</CODE> and read the
+header comments of <CODE>hardscroll.c</CODE> and <CODE>hashmap.c</CODE>; then try
+it out. You can also test the hardware-scrolling optimization separately
+with <CODE>hardscroll</CODE>. <P>
+
+There's one other interactive tester, <CODE>tctest</CODE>, that exercises
+translation between termcap and terminfo formats. If you have a serious
+need to run this, you probably belong on our development team! <P>
+
+<H1><A NAME="ncurslib">A Tour of the Ncurses Library</A></H1>
+
+<H2><A NAME="loverview">Library Overview</A></H2>
+
+Most of the library is superstructure -- fairly trivial convenience
+interfaces to a small set of basic functions and data structures used
+to manipulate the virtual screen (in particular, none of this code
+does any I/O except through calls to more fundamental modules
+described below). The files
+<blockquote>
+<CODE>
+lib_addch.c
+lib_bkgd.c
+lib_box.c
+lib_chgat.c
+lib_clear.c
+lib_clearok.c
+lib_clrbot.c
+lib_clreol.c
+lib_colorset.c
+lib_data.c
+lib_delch.c
+lib_delwin.c
+lib_echo.c
+lib_erase.c
+lib_gen.c
+lib_getstr.c
+lib_hline.c
+lib_immedok.c
+lib_inchstr.c
+lib_insch.c
+lib_insdel.c
+lib_insstr.c
+lib_instr.c
+lib_isendwin.c
+lib_keyname.c
+lib_leaveok.c
+lib_move.c
+lib_mvwin.c
+lib_overlay.c
+lib_pad.c
+lib_printw.c
+lib_redrawln.c
+lib_scanw.c
+lib_screen.c
+lib_scroll.c
+lib_scrollok.c
+lib_scrreg.c
+lib_set_term.c
+lib_slk.c
+lib_slkatr_set.c
+lib_slkatrof.c
+lib_slkatron.c
+lib_slkatrset.c
+lib_slkattr.c
+lib_slkclear.c
+lib_slkcolor.c
+lib_slkinit.c
+lib_slklab.c
+lib_slkrefr.c
+lib_slkset.c
+lib_slktouch.c
+lib_touch.c
+lib_unctrl.c
+lib_vline.c
+lib_wattroff.c
+lib_wattron.c
+lib_window.c
+</CODE>
+</blockquote>
+are all in this category. They are very
+unlikely to need change, barring bugs or some fundamental
+reorganization in the underlying data structures. <P>
+
+These files are used only for debugging support:
+<blockquote><code>
+lib_trace.c
+lib_traceatr.c
+lib_tracebits.c
+lib_tracechr.c
+lib_tracedmp.c
+lib_tracemse.c
+trace_buf.c
+</blockquote></code>
+It is rather unlikely you will ever need to change these, unless
+you want to introduce a new debug trace level for some reasoon.<P>
+
+There is another group of files that do direct I/O via <EM>tputs()</EM>,
+computations on the terminal capabilities, or queries to the OS
+environment, but nevertheless have only fairly low complexity. These
+include:
+<blockquote><code>
+lib_acs.c
+lib_beep.c
+lib_color.c
+lib_endwin.c
+lib_initscr.c
+lib_longname.c
+lib_newterm.c
+lib_options.c
+lib_termcap.c
+lib_ti.c
+lib_tparm.c
+lib_tputs.c
+lib_vidattr.c
+read_entry.c.
+</blockquote></code>
+They are likely to need revision only if
+ncurses is being ported to an environment without an underlying
+terminfo capability representation. <P>
+
+These files
+have serious hooks into
+the tty driver and signal facilities:
+<blockquote><code>
+lib_kernel.c
+lib_baudrate.c
+lib_raw.c
+lib_tstp.c
+lib_twait.c
+</blockquote></code>
+If you run into porting snafus
+moving the package to another UNIX, the problem is likely to be in one
+of these files.
+The file <CODE>lib_print.c</CODE> uses sleep(2) and also
+falls in this category.<P>
+
+Almost all of the real work is done in the files
+<blockquote><code>
+hardscroll.c
+hashmap.c
+lib_addch.c
+lib_doupdate.c
+lib_getch.c
+lib_mouse.c
+lib_mvcur.c
+lib_refresh.c
+lib_setup.c
+lib_vidattr.c
+</blockquote></code>
+Most of the algorithmic complexity in the
+library lives in these files.
+If there is a real bug in <STRONG>ncurses</STRONG> itself, it's probably here.
+We'll tour some of these files in detail
+below (see <A HREF="#engine">The Engine Room</A>). <P>
+
+Finally, there is a group of files that is actually most of the
+terminfo compiler. The reason this code lives in the <STRONG>ncurses</STRONG>
+library is to support fallback to /etc/termcap. These files include
+<blockquote><code>
+alloc_entry.c
+captoinfo.c
+comp_captab.c
+comp_error.c
+comp_hash.c
+comp_parse.c
+comp_scan.c
+parse_entry.c
+read_termcap.c
+write_entry.c
+</blockquote></code>
+We'll discuss these in the compiler tour. <P>
+
+<H2><A NAME="engine">The Engine Room</A></H2>
+
+<H3><A NAME="input">Keyboard Input</A></H3>
+
+All <CODE>ncurses</CODE> input funnels through the function
+<CODE>wgetch()</CODE>, defined in <CODE>lib_getch.c</CODE>. This function is
+tricky; it has to poll for keyboard and mouse events and do a running
+match of incoming input against the set of defined special keys. <P>
+
+The central data structure in this module is a FIFO queue, used to
+match multiple-character input sequences against special-key
+capabilities; also to implement pushback via <CODE>ungetch()</CODE>. <P>
+
+The <CODE>wgetch()</CODE> code distinguishes between function key
+sequences and the same sequences typed manually by doing a timed wait
+after each input character that could lead a function key sequence.
+If the entire sequence takes less than 1 second, it is assumed to have
+been generated by a function key press. <P>
+
+Hackers bruised by previous encounters with variant <CODE>select(2)</CODE>
+calls may find the code in <CODE>lib_twait.c</CODE> interesting. It deals
+with the problem that some BSD selects don't return a reliable
+time-left value. The function <CODE>timed_wait()</CODE> effectively
+simulates a System V select. <P>
+
+<H3><A NAME="mouse">Mouse Events</A></H3>
+
+If the mouse interface is active, <CODE>wgetch()</CODE> polls for mouse
+events each call, before it goes to the keyboard for input. It is
+up to <CODE>lib_mouse.c</CODE> how the polling is accomplished; it may vary
+for different devices. <P>
+
+Under xterm, however, mouse event notifications come in via the keyboard
+input stream. They are recognized by having the <STRONG>kmous</STRONG> capability
+as a prefix. This is kind of klugey, but trying to wire in recognition of
+a mouse key prefix without going through the function-key machinery would
+be just too painful, and this turns out to imply having the prefix somewhere
+in the function-key capabilities at terminal-type initialization. <P>
+
+This kluge only works because <STRONG>kmous</STRONG> isn't actually used by any
+historic terminal type or curses implementation we know of. Best
+guess is it's a relic of some forgotten experiment in-house at Bell
+Labs that didn't leave any traces in the publicly-distributed System V
+terminfo files. If System V or XPG4 ever gets serious about using it
+again, this kluge may have to change. <P>
+
+Here are some more details about mouse event handling: <P>
+
+The <CODE>lib_mouse()</CODE>code is logically split into a lower level that
+accepts event reports in a device-dependent format and an upper level that
+parses mouse gestures and filters events. The mediating data structure is a
+circular queue of event structures. <P>
+
+Functionally, the lower level's job is to pick up primitive events and
+put them on the circular queue. This can happen in one of two ways:
+either (a) <CODE>_nc_mouse_event()</CODE> detects a series of incoming
+mouse reports and queues them, or (b) code in <CODE>lib_getch.c</CODE> detects the
+<STRONG>kmous</STRONG> prefix in the keyboard input stream and calls _nc_mouse_inline
+to queue up a series of adjacent mouse reports. <P>
+
+In either case, <CODE>_nc_mouse_parse()</CODE> should be called after the
+series is accepted to parse the digested mouse reports (low-level
+events) into a gesture (a high-level or composite event). <P>
+
+<H3><A NAME="output">Output and Screen Updating</A></H3>
+
+With the single exception of character echoes during a <CODE>wgetnstr()</CODE>
+call (which simulates cooked-mode line editing in an ncurses window),
+the library normally does all its output at refresh time. <P>
+
+The main job is to go from the current state of the screen (as represented
+in the <CODE>curscr</CODE> window structure) to the desired new state (as
+represented in the <CODE>newscr</CODE> window structure), while doing as
+little I/O as possible. <P>
+
+The brains of this operation are the modules <CODE>hashmap.c</CODE>,
+<CODE>hardscroll.c</CODE> and <CODE>lib_doupdate.c</CODE>; the latter two use
+<CODE>lib_mvcur.c</CODE>. Essentially, what happens looks like this: <P>
+
+The <CODE>hashmap.c</CODE> module tries to detect vertical motion
+changes between the real and virtual screens. This information
+is represented by the oldindex members in the newscr structure.
+These are modified by vertical-motion and clear operations, and both are
+re-initialized after each update. To this change-journalling
+information, the hashmap code adds deductions made using a modified Heckel
+algorithm on hash values generated from the line contents. <P>
+
+The <CODE>hardscroll.c</CODE> module computes an optimum set of scroll,
+insertion, and deletion operations to make the indices match. It calls
+<CODE>_nc_mvcur_scrolln()</CODE> in <CODE>lib_mvcur.c</CODE> to do those motions. <P>
+
+Then <CODE>lib_doupdate.c</CODE> goes to work. Its job is to do line-by-line
+transformations of <CODE>curscr</CODE> lines to <CODE>newscr</CODE> lines. Its main
+tool is the routine <CODE>mvcur()</CODE> in <CODE>lib_mvcur.c</CODE>. This routine
+does cursor-movement optimization, attempting to get from given screen
+location A to given location B in the fewest output characters posible. <P>
+
+If you want to work on screen optimizations, you should use the fact
+that (in the trace-enabled version of the library) enabling the
+<CODE>TRACE_TIMES</CODE> trace level causes a report to be emitted after
+each screen update giving the elapsed time and a count of characters
+emitted during the update. You can use this to tell when an update
+optimization improves efficiency. <P>
+
+In the trace-enabled version of the library, it is also possible to disable
+and re-enable various optimizations at runtime by tweaking the variable
+<CODE>_nc_optimize_enable</CODE>. See the file <CODE>include/curses.h.in</CODE>
+for mask values, near the end. <P>
+
+<H1><A NAME="fmnote">The Forms and Menu Libraries</A></H1>
+
+The forms and menu libraries should work reliably in any environment you
+can port ncurses to. The only portability issue anywhere in them is what
+flavor of regular expressions the built-in form field type TYPE_REGEXP
+will recognize. <P>
+
+The configuration code prefers the POSIX regex facility, modeled on
+System V's, but will settle for BSD regexps if the former isn't available. <P>
+
+Historical note: the panels code was written primarily to assist in
+porting u386mon 2.0 (comp.sources.misc v14i001-4) to systems lacking
+panels support; u386mon 2.10 and beyond use it. This version has been
+slightly cleaned up for <CODE>ncurses</CODE>. <P>
+
+<H1><A NAME="tic">A Tour of the Terminfo Compiler</A></H1>
+
+The <STRONG>ncurses</STRONG> implementation of <STRONG>tic</STRONG> is rather complex
+internally; it has to do a trying combination of missions. This starts
+with the fact that, in addition to its normal duty of compiling
+terminfo sources into loadable terminfo binaries, it has to be able to
+handle termcap syntax and compile that too into terminfo entries. <P>
+
+The implementation therefore starts with a table-driven, dual-mode
+lexical analyzer (in <CODE>comp_scan.c</CODE>). The lexer chooses its
+mode (termcap or terminfo) based on the first `,' or `:' it finds in
+each entry. The lexer does all the work of recognizing capability
+names and values; the grammar above it is trivial, just "parse entries
+till you run out of file". <P>
+
+<H2><A NAME="nonuse">Translation of Non-<STRONG>use</STRONG> Capabilities</A></H2>
+
+Translation of most things besides <STRONG>use</STRONG> capabilities is pretty
+straightforward. The lexical analyzer's tokenizer hands each capability
+name to a hash function, which drives a table lookup. The table entry
+yields an index which is used to look up the token type in another table,
+and controls interpretation of the value. <P>
+
+One possibly interesting aspect of the implementation is the way the
+compiler tables are initialized. All the tables are generated by various
+awk/sed/sh scripts from a master table <CODE>include/Caps</CODE>; these
+scripts actually write C initializers which are linked to the compiler.
+Furthermore, the hash table is generated in the same way, so it doesn't
+have to be generated at compiler startup time (another benefit of this
+organization is that the hash table can be in shareable text space). <P>
+
+Thus, adding a new capability is usually pretty trivial, just a matter
+of adding one line to the <CODE>include/Caps</CODE> file. We'll have more
+to say about this in the section on <A HREF="#translation">Source-Form
+Translation</A>. <P>
+
+<H2><A NAME="uses">Use Capability Resolution</A></H2>
+
+The background problem that makes <STRONG>tic</STRONG> tricky isn't the capability
+translation itself, it's the resolution of <STRONG>use</STRONG> capabilities. Older
+versions would not handle forward <STRONG>use</STRONG> references for this reason
+(that is, a using terminal always had to follow its use target in the
+source file). By doing this, they got away with a simple implementation
+tactic; compile everything as it blows by, then resolve uses from compiled
+entries. <P>
+
+This won't do for <STRONG>ncurses</STRONG>. The problem is that that the whole
+compilation process has to be embeddable in the <STRONG>ncurses</STRONG> library
+so that it can be called by the startup code to translate termcap
+entries on the fly. The embedded version can't go promiscuously writing
+everything it translates out to disk -- for one thing, it will typically
+be running with non-root permissions. <P>
+
+So our <STRONG>tic</STRONG> is designed to parse an entire terminfo file into a
+doubly-linked circular list of entry structures in-core, and then do
+<STRONG>use</STRONG> resolution in-memory before writing everything out. This
+design has other advantages: it makes forward and back use-references
+equally easy (so we get the latter for free), and it makes checking for
+name collisions before they're written out easy to do. <P>
+
+And this is exactly how the embedded version works. But the stand-alone
+user-accessible version of <STRONG>tic</STRONG> partly reverts to the historical
+strategy; it writes to disk (not keeping in core) any entry with no
+<STRONG>use</STRONG> references. <P>
+
+This is strictly a core-economy kluge, implemented because the
+terminfo master file is large enough that some core-poor systems swap
+like crazy when you compile it all in memory...there have been reports of
+this process taking <STRONG>three hours</STRONG>, rather than the twenty seconds
+or less typical on the author's development box. <P>
+
+So. The executable <STRONG>tic</STRONG> passes the entry-parser a hook that
+<EM>immediately</EM> writes out the referenced entry if it has no use
+capabilities. The compiler main loop refrains from adding the entry
+to the in-core list when this hook fires. If some other entry later
+needs to reference an entry that got written immediately, that's OK;
+the resolution code will fetch it off disk when it can't find it in
+core. <P>
+
+Name collisions will still be detected, just not as cleanly. The
+<CODE>write_entry()</CODE> code complains before overwriting an entry that
+postdates the time of <STRONG>tic</STRONG>'s first call to
+<CODE>write_entry()</CODE>, Thus it will complain about overwriting
+entries newly made during the <STRONG>tic</STRONG> run, but not about
+overwriting ones that predate it. <P>
+
+<H2><A NAME="translation">Source-Form Translation</A></H2>
+
+Another use of <STRONG>tic</STRONG> is to do source translation between various termcap
+and terminfo formats. There are more variants out there than you might
+think; the ones we know about are described in the <STRONG>captoinfo(1)</STRONG>
+manual page. <P>
+
+The translation output code (<CODE>dump_entry()</CODE> in
+<CODE>ncurses/dump_entry.c</CODE>) is shared with the <STRONG>infocmp(1)</STRONG>
+utility. It takes the same internal representation used to generate
+the binary form and dumps it to standard output in a specified
+format. <P>
+
+The <CODE>include/Caps</CODE> file has a header comment describing ways you
+can specify source translations for nonstandard capabilities just by
+altering the master table. It's possible to set up capability aliasing
+or tell the compiler to plain ignore a given capability without writing
+any C code at all. <P>
+
+For circumstances where you need to do algorithmic translation, there
+are functions in <CODE>parse_entry.c</CODE> called after the parse of each
+entry that are specifically intended to encapsulate such
+translations. This, for example, is where the AIX <STRONG>box1</STRONG> capability
+get translated to an <STRONG>acsc</STRONG> string.<P>
+
+<H1><A NAME="utils">Other Utilities</A></H1>
+
+The <STRONG>infocmp</STRONG> utility is just a wrapper around the same
+entry-dumping code used by <STRONG>tic</STRONG> for source translation. Perhaps
+the one interesting aspect of the code is the use of a predicate
+function passed in to <CODE>dump_entry()</CODE> to control which
+capabilities are dumped. This is necessary in order to handle both
+the ordinary De-compilation case and entry difference reporting. <P>
+
+The <STRONG>tput</STRONG> and <STRONG>clear</STRONG> utilities just do an entry load
+followed by a <CODE>tputs()</CODE> of a selected capability. <P>
+
+<H1><A NAME="style">Style Tips for Developers</A></H1>
+
+See the TO-DO file in the top-level directory of the source distribution
+for additions that would be particularly useful. <P>
+
+The prefix <CODE>_nc_</CODE> should be used on library public functions that are
+not part of the curses API in order to prevent pollution of the
+application namespace.
+
+If you have to add to or modify the function prototypes in curses.h.in,
+read ncurses/MKlib_gen.sh first so you can avoid breaking XSI conformance.
+
+Please join the ncurses mailing list. See the INSTALL file in the
+top level of the distribution for details on the list. <P>
+
+Look for the string <CODE>FIXME</CODE> in source files to tag minor bugs
+and potential problems that could use fixing. <P>
+
+Don't try to auto-detect OS features in the main body of the C code.
+That's the job of the configuration system. <P>
+
+To hold down complexity, do make your code data-driven. Especially,
+if you can drive logic from a table filtered out of
+<CODE>include/Caps</CODE>, do it. If you find you need to augment the
+data in that file in order to generate the proper table, that's still
+preferable to ad-hoc code -- that's why the fifth field (flags) is
+there. <P>
+
+Have fun! <P>
+
+<H1><A NAME="port">Porting Hints</A></H1>
+
+The following notes are intended to be a first step towards DOS and Macintosh
+ports of the ncurses libraries. <P>
+
+The following library modules are `pure curses'; they operate only on
+the curses internal structures, do all output through other curses
+calls (not including <CODE>tputs()</CODE> and <CODE>putp()</CODE>) and do not
+call any other UNIX routines such as signal(2) or the stdio library.
+Thus, they should not need to be modified for single-terminal
+ports. <P>
+
+<blockquote><code>
+lib_addch.c
+lib_addstr.c
+lib_bkgd.c
+lib_box.c
+lib_clear.c
+lib_clrbot.c
+lib_clreol.c
+lib_delch.c
+lib_delwin.c
+lib_erase.c
+lib_inchstr.c
+lib_insch.c
+lib_insdel.c
+lib_insstr.c
+lib_keyname.c
+lib_move.c
+lib_mvwin.c
+lib_newwin.c
+lib_overlay.c
+lib_pad.c
+lib_printw.c
+lib_refresh.c
+lib_scanw.c
+lib_scroll.c
+lib_scrreg.c
+lib_set_term.c
+lib_touch.c
+lib_tparm.c
+lib_tputs.c
+lib_unctrl.c
+lib_window.c
+panel.c
+</blockquote></code>
+<P>
+
+This module is pure curses, but calls outstr(): <P>
+
+<blockquote><code>
+lib_getstr.c
+</blockquote></code>
+<P>
+
+These modules are pure curses, except that they use <CODE>tputs()</CODE>
+and <CODE>putp()</CODE>: <P>
+
+<blockquote><code>
+lib_beep.c
+lib_color.c
+lib_endwin.c
+lib_options.c
+lib_slk.c
+lib_vidattr.c
+</blockquote></code>
+<P>
+
+This modules assist in POSIX emulation on non-POSIX systems: <P>
+<DL>
+<DT> sigaction.c
+<DD> signal calls
+</DL>
+
+The following source files will not be needed for a
+single-terminal-type port. <P>
+
+<blockquote><code>
+alloc_entry.c
+captoinfo.c
+clear.c
+comp_captab.c
+comp_error.c
+comp_hash.c
+comp_main.c
+comp_parse.c
+comp_scan.c
+dump_entry.c
+infocmp.c
+parse_entry.c
+read_entry.c
+tput.c
+write_entry.c
+</blockquote></code>
+<P>
+
+The following modules will use open()/read()/write()/close()/lseek() on files,
+but no other OS calls. <P>
+
+<DL>
+<DT>lib_screen.c
+<DD>used to read/write screen dumps
+<DT>lib_trace.c
+<DD>used to write trace data to the logfile
+</DL>
+
+Modules that would have to be modified for a port start here: <P>
+
+The following modules are `pure curses' but contain assumptions inappropriate
+for a memory-mapped port. <P>
+
+<dl>
+<dt>lib_longname.c<dd>assumes there may be multiple terminals
+<dt>lib_acs.c<dd>assumes acs_map as a double indirection
+<dt>lib_mvcur.c<dd>assumes cursor moves have variable cost
+<dt>lib_termcap.c<dd>assumes there may be multiple terminals
+<dt>lib_ti.c<dd>assumes there may be multiple terminals
+</dl>
+
+The following modules use UNIX-specific calls:
+
+<dl>
+<dt>lib_doupdate.c<dd>input checking
+<dt>lib_getch.c<dd>read()
+<dt>lib_initscr.c<dd>getenv()
+<dt>lib_newterm.c
+<dt>lib_baudrate.c
+<dt>lib_kernel.c<dd>various tty-manipulation and system calls
+<dt>lib_raw.c<dd>various tty-manipulation calls
+<dt>lib_setup.c<dd>various tty-manipulation calls
+<dt>lib_restart.c<dd>various tty-manipulation calls
+<dt>lib_tstp.c<dd>signal-manipulation calls
+<dt>lib_twait.c<dd>gettimeofday(), select().
+</dl>
+
+<HR>
+<ADDRESS>Eric S. Raymond &lt;esr@snark.thyrsus.com&gt;</ADDRESS>
+(Note: This is <EM>not</EM> the <A HREF="#bugtrack">bug address</A>!)
+</BODY>
+</HTML>
diff --git a/contrib/ncurses/misc/makedef.cmd b/contrib/ncurses/misc/makedef.cmd
new file mode 100644
index 000000000000..f3d9740eff68
--- /dev/null
+++ b/contrib/ncurses/misc/makedef.cmd
@@ -0,0 +1,151 @@
+/*
+ * $Id: makedef.cmd,v 1.4 1998/11/22 03:14:08 tom Exp $
+ *
+ * Author: Juan Jose Garcia Ripoll <worm@arrakis.es>.
+ * Webpage: http://www.arrakis.es/~worm/
+ *
+ * makedef.cmd - update a DLL export list using a newly created library file
+ * in a.out format, plus an old .DEF file.
+ *
+ * standard output gets a sorted list with all entrypoints with entrycodes.
+ * This list, plus a few .def sentences (LIBRARY, DESCRIPTION and EXPORT)
+ * is used to build a new .def file.
+ *
+ * `_nc_*' symbols are ignored.
+ *
+ * returns 1 when the old def_file is corrupted -- that is, export items are
+ * not properly formatted.
+ *
+ * returns 0 if everything went OK.
+ */
+
+parse arg lib_file def_file
+
+lib_file = translate(lib_file,'\','/')
+def_file = translate(def_file,'\','/')
+
+call CleanQueue
+
+/*
+ * `codes' is the stem that links a code to every symbol
+ * `names' is the stem where symbols are stored sequentially
+ * `last' is the index of the last symbol defined
+ */
+last = 0
+used. = 0
+codes. = 0
+names. = ''
+
+tmp_name = 'foo.tmp'
+
+/*
+ * This sed expression cleans empty lines, comments and special .DEF
+ * commands, such as LIBRARY..., EXPORTS..., etc
+ */
+tidy_up = '"/^[A-Z]/d;s/[ ][ ]*/ /g;s/;.*$//g;s/^[ ]*//g;/^[ ]*$/d"'
+
+/*
+ * First we find all public symbols (functions and variables). Next we
+ * concatenate this list with the old one, sorting it and wiping out
+ * all unused data (comments, DLL directives, blanks, etc). All this
+ * information is pushed into a REXX private list with the RXQUEUE
+ * utility program.
+ */
+'@echo off'
+'emxexp -u' lib_file '>' tmp_name
+'cat' tmp_name def_file '| sed' tidy_up '| sort > foo2.tmp'
+'type foo2.tmp | rxqueue'
+'del' tmp_name '1>NUL'
+
+/*
+ * This loop runs over the queue items
+ */
+do while queued() > 0
+ /*
+ * We retrieve the symbol name (NEW_NAME) and its number (NEW_NUMBER)
+ * When the line comes from `emximp's output, there's no number, so
+ * we assign it the special value 0.
+ */
+ parse pull new_symbol '@'new_code rest
+ if Left(new_symbol,1) = '"' then
+ parse var new_symbol '"' new_name '"' rest
+ else
+ do
+ echo 'Symbol 'new_symbol' was not quoted'
+ new_name = new_symbol
+ end
+
+ if new_code = '' then
+ new_code = 0
+ /*
+ * Here, one would place all smart checks that would kill unused symbols.
+ * However, export tables are not that big, so why bothering?
+ if Left(new_name,4) = '_nc_' then
+ iterate
+ */
+ /*
+ * The algorithm:
+ * IF (this is the 2nd time the symbol appears) THEN
+ * (this symbol comes from a .DEF file)
+ * it has a valid code that we store
+ * we mark that code as used
+ * ELIF (it has no number) THEN
+ * (it's a new symbol)
+ * we increase the counter of defined symbols
+ * we assign it the special number 0
+ * (later on it'll be assigned an unused export code)
+ * ELSE
+ * this symbol was in the old DLL and it's no longer
+ * here, so we skip it.
+ */
+ select
+ when new_name = '' then
+ 'echo Warning: empty symbol found 1>&2'
+ when names.last = new_name then
+ do
+ codes.last = new_code
+ used.new_code = 1
+ end
+ when new_code = 0 then
+ do
+ last = last + 1
+ names.last = new_name
+ codes.last = 0
+ end
+ otherwise
+ 'echo Warning: symbol "'new_name'" has disappeared 1>&2'
+ end /* select */
+end /* do while queued() */
+
+/*
+ * Finally we scan the stem, writing out all symbols with export codes.
+ * Those that did not have a valid one (just 0) are assigned a new one.
+ */
+new_code = 1
+inx = 1
+do while inx <= last
+ if codes.inx = 0 then
+ do
+ do while used.new_code \= 0
+ new_code = new_code + 1
+ end
+ codes.inx = new_code
+ used.new_code = 1
+ end
+ say ' "'names.inx'" @'codes.inx' NONAME'
+ inx = inx + 1
+end
+'del foo2.tmp 1>NUL'
+exit 0
+
+/*
+ * Cleans the REXX queue by pulling and forgetting every line.
+ * This is needed, at least, when `makedef.cmd' starts, because an aborted
+ * REXX program might have left some rubbish in.
+ */
+CleanQueue: procedure
+ do while queued() > 0
+ parse pull foo
+ end
+return
+
diff --git a/contrib/ncurses/misc/makellib b/contrib/ncurses/misc/makellib
new file mode 100755
index 000000000000..fe9f99f18517
--- /dev/null
+++ b/contrib/ncurses/misc/makellib
@@ -0,0 +1,162 @@
+#!/bin/sh
+##############################################################################
+# Copyright (c) 1998 Free Software Foundation, Inc. #
+# #
+# Permission is hereby granted, free of charge, to any person obtaining a #
+# copy of this software and associated documentation files (the "Software"), #
+# to deal in the Software without restriction, including without limitation #
+# the rights to use, copy, modify, merge, publish, distribute, distribute #
+# with modifications, sublicense, and/or sell copies of the Software, and to #
+# permit persons to whom the Software is furnished to do so, subject to the #
+# following conditions: #
+# #
+# The above copyright notice and this permission notice shall be included in #
+# all copies or substantial portions of the Software. #
+# #
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR #
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, #
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL #
+# THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER #
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING #
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER #
+# DEALINGS IN THE SOFTWARE. #
+# #
+# Except as contained in this notice, the name(s) of the above copyright #
+# holders shall not be used in advertising or otherwise to promote the sale, #
+# use or other dealings in this Software without prior written #
+# authorization. #
+##############################################################################
+#
+# Author: Thomas E. Dickey <dickey@clark.net> 1996,1997
+#
+# $Id: makellib,v 1.7 1998/02/11 12:13:50 tom Exp $
+# System-dependent wrapper for 'lint' that creates a lint-library via the
+# following method (XXX is the name of the library):
+# a. If the file llib-lXXX doesn't exist, create it using the make-rule
+# b. Process llib-lXXX with the system's lint utility, making
+# llib-lXXX.ln
+# c. Install llib-lXXX.ln in the lib directory.
+#
+# Using the intermediate file llib-lXXX bypasses a weakness of lint (passing
+# through warning messages from the original source-files).
+#
+# There are two drawbacks to this approach:
+# a. On a few systems, you'll have to manually-edit the llib-lXXX file
+# to get a usable lint-library (not all C-preprocessors work well).
+# b. The system's lint utility won't recognize -lXXX as a lint-library
+# (Use tdlint as a wrapper; it's designed for this).
+#
+# Parameters:
+# $1 = library name
+# $* = C-preprocessor options
+#
+ARCH=`uname -s`
+if test "x$ARCH" = "xSunOS" ; then
+ case `uname -r` in
+ 5.*) ARCH=Solaris
+ ;;
+ esac
+fi
+#
+DST="$HOME/lib/$ARCH/lint"
+OPT=""
+LLIB=""
+llib=""
+#
+while test $# != 0
+do
+ case $1 in
+ -L*)
+ DST="$DST `echo $1|sed -e 's/^-L//'`"
+ ;;
+ -*)
+ OPT="$OPT $1"
+ ;;
+ *)
+ if test -z "$LLIB"
+ then
+ LLIB=$1
+ else
+ llib=llib-l$1
+ fi
+ ;;
+ esac
+ shift
+done
+
+if test -z "$LLIB"
+then
+ echo '? no library name specified'
+ exit 1
+elif test -z "$llib"
+then
+ llib="llib-l$LLIB"
+fi
+
+if test ! -f $llib ; then
+ if ( make $llib )
+ then
+ :
+ else
+ exit 1
+ fi
+fi
+
+rm -f $llib.ln $llib.c
+TARGET=$LLIB
+
+case "$ARCH" in
+AIX)
+ CREATE="-uvxo$LLIB -Nn4000"
+ TARGET=$llib.c
+ ln $llib $TARGET
+ ;;
+Solaris)
+ CREATE="-C$llib"
+ TARGET=$llib.c
+ ln $llib $TARGET
+ ;;
+CLIX)
+ CREATE="-DLINTLIBRARY -vxo$LLIB"
+ TARGET=$llib.c
+ ln $llib $TARGET
+ ;;
+IRIX*)
+ CREATE="-DLINTLIBRARY -vxyo$LLIB"
+ TARGET=$llib.c
+ ln $llib $TARGET
+ ;;
+UNIX_SV)
+ CREATE="-DLINTLIBRARY -vxyo$LLIB"
+ TARGET=$llib.c
+ ln $llib $TARGET
+ ;;
+*)
+ echo "Sorry. I do not know how to build a lint-library for $ARCH"
+ exit 1
+esac
+
+echo OPT "$OPT"
+echo TARGET "$TARGET"
+echo LIBNAME "$llib"
+if ( lint $CREATE $OPT $TARGET )
+then
+ if test -f $llib.ln
+ then
+ for p in $HOME/lib $HOME/lib/$ARCH $HOME/lib/$ARCH/lint
+ do
+ if test ! -d $p
+ then
+ mkdir $p
+ fi
+ done
+ for p in $DST
+ do
+ cp $llib.ln $p/
+ done
+ rm -f $llib.ln
+ fi
+fi
+if test "x$TARGET" = "x$llib.c" ; then
+ rm -f $TARGET
+fi
diff --git a/contrib/ncurses/misc/menu.def b/contrib/ncurses/misc/menu.def
new file mode 100644
index 000000000000..7121083ffc6e
--- /dev/null
+++ b/contrib/ncurses/misc/menu.def
@@ -0,0 +1,84 @@
+LIBRARY menu4 INITINSTANCE TERMINSTANCE
+DESCRIPTION "NCurses-4-2-981212, module menu"
+CODE LOADONCALL
+DATA LOADONCALL NONSHARED MULTIPLE
+EXPORTS
+ "_nc_Calculate_Item_Length_and_Width" @11 NONAME
+ "_nc_Connect_Items" @38 NONAME
+ "_nc_Default_Item" @63 NONAME
+ "_nc_Default_Menu" @64 NONAME
+ "_nc_Disconnect_Items" @65 NONAME
+ "_nc_Draw_Menu" @66 NONAME
+ "_nc_Link_Items" @67 NONAME
+ "_nc_Match_Next_Character_In_Item_Name" @68 NONAME
+ "_nc_New_TopRow_and_CurrentItem" @69 NONAME
+ "_nc_Post_Item" @70 NONAME
+ "_nc_Show_Menu" @71 NONAME
+ "_nc_ada_normalize_item_opts" @72 NONAME
+ "_nc_ada_normalize_menu_opts" @73 NONAME
+ "_nc_get_item" @74 NONAME
+ "_nc_menu_cursor_pos" @75 NONAME
+ "current_item" @2 NONAME
+ "free_item" @23 NONAME
+ "free_menu" @24 NONAME
+ "item_count" @25 NONAME
+ "item_description" @14 NONAME
+ "item_index" @26 NONAME
+ "item_init" @7 NONAME
+ "item_name" @15 NONAME
+ "item_opts" @5 NONAME
+ "item_opts_off" @27 NONAME
+ "item_opts_on" @28 NONAME
+ "item_term" @8 NONAME
+ "item_userptr" @18 NONAME
+ "item_value" @60 NONAME
+ "item_visible" @61 NONAME
+ "menu_back" @20 NONAME
+ "menu_driver" @29 NONAME
+ "menu_fore" @21 NONAME
+ "menu_format" @62 NONAME
+ "menu_grey" @22 NONAME
+ "menu_init" @9 NONAME
+ "menu_items" @1 NONAME
+ "menu_mark" @16 NONAME
+ "menu_opts" @6 NONAME
+ "menu_opts_off" @30 NONAME
+ "menu_opts_on" @31 NONAME
+ "menu_pad" @32 NONAME
+ "menu_pattern" @17 NONAME
+ "menu_request_by_name" @76 NONAME
+ "menu_request_name" @77 NONAME
+ "menu_spacing" @78 NONAME
+ "menu_sub" @12 NONAME
+ "menu_term" @10 NONAME
+ "menu_userptr" @19 NONAME
+ "menu_win" @13 NONAME
+ "new_item" @3 NONAME
+ "new_menu" @4 NONAME
+ "pos_menu_cursor" @33 NONAME
+ "post_menu" @34 NONAME
+ "scale_menu" @35 NONAME
+ "set_current_item" @36 NONAME
+ "set_item_init" @37 NONAME
+ "set_item_opts" @39 NONAME
+ "set_item_term" @40 NONAME
+ "set_item_userptr" @41 NONAME
+ "set_item_value" @42 NONAME
+ "set_menu_back" @43 NONAME
+ "set_menu_fore" @44 NONAME
+ "set_menu_format" @45 NONAME
+ "set_menu_grey" @46 NONAME
+ "set_menu_init" @47 NONAME
+ "set_menu_items" @48 NONAME
+ "set_menu_mark" @49 NONAME
+ "set_menu_opts" @50 NONAME
+ "set_menu_pad" @51 NONAME
+ "set_menu_pattern" @52 NONAME
+ "set_menu_spacing" @79 NONAME
+ "set_menu_sub" @53 NONAME
+ "set_menu_term" @54 NONAME
+ "set_menu_userptr" @55 NONAME
+ "set_menu_win" @56 NONAME
+ "set_top_row" @57 NONAME
+ "top_row" @58 NONAME
+ "unpost_menu" @59 NONAME
diff --git a/contrib/ncurses/misc/menu.ref b/contrib/ncurses/misc/menu.ref
new file mode 100644
index 000000000000..cee964f7df1b
--- /dev/null
+++ b/contrib/ncurses/misc/menu.ref
@@ -0,0 +1,73 @@
+LIBRARY MENU2 INITINSTANCE
+DESCRIPTION 'NCurses 1.9.9e-1 for OS/2 - menu library'
+EXPORTS
+ "menu_items" @1 ;NONAME
+ "current_item" @2 ;NONAME
+ "new_item" @3 ;NONAME
+
+ "new_menu" @4 ;NONAME
+
+ "item_opts" @5 ;NONAME
+ "menu_opts" @6 ;NONAME
+
+ "item_init" @7 ;NONAME
+ "item_term" @8 ;NONAME
+ "menu_init" @9 ;NONAME
+ "menu_term" @10 ;NONAME
+
+ "menu_sub" @12 ;NONAME
+ "menu_win" @13 ;NONAME
+
+ "item_description" @14 ;NONAME
+ "item_name" @15 ;NONAME
+ "menu_mark" @16 ;NONAME
+ "menu_pattern" @17 ;NONAME
+
+ "item_userptr" @18 ;NONAME
+ "menu_userptr" @19 ;NONAME
+
+ "menu_back" @20 ;NONAME
+ "menu_fore" @21 ;NONAME
+ "menu_grey" @22 ;NONAME
+
+ "free_item" @23 ;NONAME
+ "free_menu" @24 ;NONAME
+ "item_count" @25 ;NONAME
+ "item_index" @26 ;NONAME
+ "item_opts_off" @27 ;NONAME
+ "item_opts_on" @28 ;NONAME
+ "menu_driver" @29 ;NONAME
+ "menu_opts_off" @30 ;NONAME
+ "menu_opts_on" @31 ;NONAME
+ "menu_pad" @32 ;NONAME
+ "pos_menu_cursor" @33 ;NONAME
+ "post_menu" @34 ;NONAME
+ "scale_menu" @35 ;NONAME
+ "set_current_item" @36 ;NONAME
+ "set_item_init" @37 ;NONAME
+ "set_item_opts" @39 ;NONAME
+ "set_item_term" @40 ;NONAME
+ "set_item_userptr" @41 ;NONAME
+ "set_item_value" @42 ;NONAME
+ "set_menu_back" @43 ;NONAME
+ "set_menu_fore" @44 ;NONAME
+ "set_menu_format" @45 ;NONAME
+ "set_menu_grey" @46 ;NONAME
+ "set_menu_init" @47 ;NONAME
+ "set_menu_items" @48 ;NONAME
+ "set_menu_mark" @49 ;NONAME
+ "set_menu_opts" @50 ;NONAME
+ "set_menu_pad" @51 ;NONAME
+ "set_menu_pattern" @52 ;NONAME
+ "set_menu_sub" @53 ;NONAME
+ "set_menu_term" @54 ;NONAME
+ "set_menu_userptr" @55 ;NONAME
+ "set_menu_win" @56 ;NONAME
+ "set_top_row" @57 ;NONAME
+ "top_row" @58 ;NONAME
+ "unpost_menu" @59 ;NONAME
+
+ "item_value" @60 ;NONAME
+ "item_visible" @61 ;NONAME
+
+ "menu_format" @62 ;NONAME
diff --git a/contrib/ncurses/misc/ncurses-intro.doc b/contrib/ncurses/misc/ncurses-intro.doc
new file mode 100644
index 000000000000..e45ca3530f20
--- /dev/null
+++ b/contrib/ncurses/misc/ncurses-intro.doc
@@ -0,0 +1,2530 @@
+
+ Writing Programs with NCURSES
+
+ by Eric S. Raymond and Zeyd M. Ben-Halim
+ updates since release 1.9.9e by Thomas Dickey
+
+ Contents
+
+ * Introduction
+ + A Brief History of Curses
+ + Scope of This Document
+ + Terminology
+ * The Curses Library
+ + An Overview of Curses
+ o Compiling Programs using Curses
+ o Updating the Screen
+ o Standard Windows and Function Naming Conventions
+ o Variables
+ + Using the Library
+ o Starting up
+ o Output
+ o Input
+ o Using Forms Characters
+ o Character Attributes and Color
+ o Mouse Interfacing
+ o Finishing Up
+ + Function Descriptions
+ o Initialization and Wrapup
+ o Causing Output to the Terminal
+ o Low-Level Capability Access
+ o Debugging
+ + Hints, Tips, and Tricks
+ o Some Notes of Caution
+ o Temporarily Leaving ncurses Mode
+ o Using ncurses under xterm
+ o Handling Multiple Terminal Screens
+ o Testing for Terminal Capabilities
+ o Tuning for Speed
+ o Special Features of ncurses
+ + Compatibility with Older Versions
+ o Refresh of Overlapping Windows
+ o Background Erase
+ + XSI Curses Conformance
+ * The Panels Library
+ + Compiling With the Panels Library
+ + Overview of Panels
+ + Panels, Input, and the Standard Screen
+ + Hiding Panels
+ + Miscellaneous Other Facilities
+ * The Menu Library
+ + Compiling with the menu Library
+ + Overview of Menus
+ + Selecting items
+ + Menu Display
+ + Menu Windows
+ + Processing Menu Input
+ + Miscellaneous Other Features
+ * The Forms Library
+ + Compiling with the forms Library
+ + Overview of Forms
+ + Creating and Freeing Fields and Forms
+ + Fetching and Changing Field Attributes
+ o Fetching Size and Location Data
+ o Changing the Field Location
+ o The Justification Attribute
+ o Field Display Attributes
+ o Field Option Bits
+ o Field Status
+ o Field User Pointer
+ + Variable-Sized Fields
+ + Field Validation
+ o TYPE_ALPHA
+ o TYPE_ALNUM
+ o TYPE_ENUM
+ o TYPE_INTEGER
+ o TYPE_NUMERIC
+ o TYPE_REGEXP
+ + Direct Field Buffer Manipulation
+ + Attributes of Forms
+ + Control of Form Display
+ + Input Processing in the Forms Driver
+ o Page Navigation Requests
+ o Inter-Field Navigation Requests
+ o Intra-Field Navigation Requests
+ o Scrolling Requests
+ o Field Editing Requests
+ o Order Requests
+ o Application Commands
+ + Field Change Hooks
+ + Field Change Commands
+ + Form Options
+ + Custom Validation Types
+ o Union Types
+ o New Field Types
+ o Validation Function Arguments
+ o Order Functions For Custom Types
+ o Avoiding Problems
+ _________________________________________________________________
+
+ Introduction
+
+ This document is an introduction to programming with curses. It is not
+ an exhaustive reference for the curses Application Programming
+ Interface (API); that role is filled by the curses manual pages.
+ Rather, it is intended to help C programmers ease into using the
+ package.
+
+ This document is aimed at C applications programmers not yet
+ specifically familiar with ncurses. If you are already an experienced
+ curses programmer, you should nevertheless read the sections on Mouse
+ Interfacing, Debugging, Compatibility with Older Versions, and Hints,
+ Tips, and Tricks. These will bring you up to speed on the special
+ features and quirks of the ncurses implementation. If you are not so
+ experienced, keep reading.
+
+ The curses package is a subroutine library for terminal-independent
+ screen-painting and input-event handling which presents a high level
+ screen model to the programmer, hiding differences between terminal
+ types and doing automatic optimization of output to change one screen
+ full of text into another. Curses uses terminfo, which is a database
+ format that can describe the capabilities of thousands of different
+ terminals.
+
+ The curses API may seem something of an archaism on UNIX desktops
+ increasingly dominated by X, Motif, and Tcl/Tk. Nevertheless, UNIX
+ still supports tty lines and X supports xterm(1); the curses API has
+ the advantage of (a) back-portability to character-cell terminals, and
+ (b) simplicity. For an application that does not require bit-mapped
+ graphics and multiple fonts, an interface implementation using curses
+ will typically be a great deal simpler and less expensive than one
+ using an X toolkit.
+
+A Brief History of Curses
+
+ Historically, the first ancestor of curses was the routines written to
+ provide screen-handling for the game rogue; these used the
+ already-existing termcap database facility for describing terminal
+ capabilities. These routines were abstracted into a documented library
+ and first released with the early BSD UNIX versions.
+
+ System III UNIX from Bell Labs featured a rewritten and much-improved
+ curses library. It introduced the terminfo format. Terminfo is based
+ on Berkeley's termcap database, but contains a number of improvements
+ and extensions. Parameterized capabilities strings were introduced,
+ making it possible to describe multiple video attributes, and colors
+ and to handle far more unusual terminals than possible with termcap.
+ In the later AT&T System V releases, curses evolved to use more
+ facilities and offer more capabilities, going far beyond BSD curses in
+ power and flexibility.
+
+Scope of This Document
+
+ This document describes ncurses, a free implementation of the System V
+ curses API with some clearly marked extensions. It includes the
+ following System V curses features:
+
+ * Support for multiple screen highlights (BSD curses could only
+ handle one `standout' highlight, usually reverse-video).
+ * Support for line- and box-drawing using forms characters.
+ * Recognition of function keys on input.
+ * Color support.
+ * Support for pads (windows of larger than screen size on which the
+ screen or a subwindow defines a viewport).
+
+ Also, this package makes use of the insert and delete line and
+ character features of terminals so equipped, and determines how to
+ optimally use these features with no help from the programmer. It
+ allows arbitrary combinations of video attributes to be displayed,
+ even on terminals that leave ``magic cookies'' on the screen to mark
+ changes in attributes.
+
+ The ncurses package can also capture and use event reports from a
+ mouse in some environments (notably, xterm under the X window system).
+ This document includes tips for using the mouse.
+
+ The ncurses package was originated by Pavel Curtis. The original
+ maintainer of this package is Zeyd Ben-Halim <zmbenhal@netcom.com>.
+ Eric S. Raymond <esr@snark.thyrsus.com> wrote many of the new features
+ in versions after 1.8.1 and wrote most of this introduction. Jürgen
+ Pfeifer wrote all of the menu and forms code as well as the Ada95
+ binding. Ongoing work is being done by Thomas Dickey and Jürgen
+ Pfeifer. Florian La Roche acts as the maintainer for the Free Software
+ Foundation, which holds the copyright on ncurses. Contact the current
+ maintainers at bug-ncurses@gnu.org.
+
+ This document also describes the panels extension library, similarly
+ modeled on the SVr4 panels facility. This library allows you to
+ associate backing store with each of a stack or deck of overlapping
+ windows, and provides operations for moving windows around in the
+ stack that change their visibility in the natural way (handling window
+ overlaps).
+
+ Finally, this document describes in detail the menus and forms
+ extension libraries, also cloned from System V, which support easy
+ construction and sequences of menus and fill-in forms.
+
+Terminology
+
+ In this document, the following terminology is used with reasonable
+ consistency:
+
+ window
+ A data structure describing a sub-rectangle of the screen
+ (possibly the entire screen). You can write to a window as
+ though it were a miniature screen, scrolling independently of
+ other windows on the physical screen.
+
+ screens
+ A subset of windows which are as large as the terminal screen,
+ i.e., they start at the upper left hand corner and encompass
+ the lower right hand corner. One of these, stdscr, is
+ automatically provided for the programmer.
+
+ terminal screen
+ The package's idea of what the terminal display currently looks
+ like, i.e., what the user sees now. This is a special screen.
+
+ The Curses Library
+
+An Overview of Curses
+
+ Compiling Programs using Curses
+
+ In order to use the library, it is necessary to have certain types and
+ variables defined. Therefore, the programmer must have a line:
+ #include <curses.h>
+
+ at the top of the program source. The screen package uses the Standard
+ I/O library, so <curses.h> includes <stdio.h>. <curses.h> also
+ includes <termios.h>, <termio.h>, or <sgtty.h> depending on your
+ system. It is redundant (but harmless) for the programmer to do these
+ includes, too. In linking with curses you need to have -lncurses in
+ your LDFLAGS or on the command line. There is no need for any other
+ libraries.
+
+ Updating the Screen
+
+ In order to update the screen optimally, it is necessary for the
+ routines to know what the screen currently looks like and what the
+ programmer wants it to look like next. For this purpose, a data type
+ (structure) named WINDOW is defined which describes a window image to
+ the routines, including its starting position on the screen (the (y,
+ x) coordinates of the upper left hand corner) and its size. One of
+ these (called curscr, for current screen) is a screen image of what
+ the terminal currently looks like. Another screen (called stdscr, for
+ standard screen) is provided by default to make changes on.
+
+ A window is a purely internal representation. It is used to build and
+ store a potential image of a portion of the terminal. It doesn't bear
+ any necessary relation to what is really on the terminal screen; it's
+ more like a scratchpad or write buffer.
+
+ To make the section of physical screen corresponding to a window
+ reflect the contents of the window structure, the routine refresh()
+ (or wrefresh() if the window is not stdscr) is called.
+
+ A given physical screen section may be within the scope of any number
+ of overlapping windows. Also, changes can be made to windows in any
+ order, without regard to motion efficiency. Then, at will, the
+ programmer can effectively say ``make it look like this,'' and let the
+ package implementation determine the most efficient way to repaint the
+ screen.
+
+ Standard Windows and Function Naming Conventions
+
+ As hinted above, the routines can use several windows, but two are
+ automatically given: curscr, which knows what the terminal looks like,
+ and stdscr, which is what the programmer wants the terminal to look
+ like next. The user should never actually access curscr directly.
+ Changes should be made to through the API, and then the routine
+ refresh() (or wrefresh()) called.
+
+ Many functions are defined to use stdscr as a default screen. For
+ example, to add a character to stdscr, one calls addch() with the
+ desired character as argument. To write to a different window. use the
+ routine waddch() (for `w'indow-specific addch()) is provided. This
+ convention of prepending function names with a `w' when they are to be
+ applied to specific windows is consistent. The only routines which do
+ not follow it are those for which a window must always be specified.
+
+ In order to move the current (y, x) coordinates from one point to
+ another, the routines move() and wmove() are provided. However, it is
+ often desirable to first move and then perform some I/O operation. In
+ order to avoid clumsiness, most I/O routines can be preceded by the
+ prefix 'mv' and the desired (y, x) coordinates prepended to the
+ arguments to the function. For example, the calls
+ move(y, x);
+ addch(ch);
+
+ can be replaced by
+ mvaddch(y, x, ch);
+
+ and
+ wmove(win, y, x);
+ waddch(win, ch);
+
+ can be replaced by
+ mvwaddch(win, y, x, ch);
+
+ Note that the window description pointer (win) comes before the added
+ (y, x) coordinates. If a function requires a window pointer, it is
+ always the first parameter passed.
+
+ Variables
+
+ The curses library sets some variables describing the terminal
+ capabilities.
+ type name description
+ ------------------------------------------------------------------
+ int LINES number of lines on the terminal
+ int COLS number of columns on the terminal
+
+ The curses.h also introduces some #define constants and types of
+ general usefulness:
+
+ bool
+ boolean type, actually a `char' (e.g., bool doneit;)
+
+ TRUE
+ boolean `true' flag (1).
+
+ FALSE
+ boolean `false' flag (0).
+
+ ERR
+ error flag returned by routines on a failure (-1).
+
+ OK
+ error flag returned by routines when things go right.
+
+Using the Library
+
+ Now we describe how to actually use the screen package. In it, we
+ assume all updating, reading, etc. is applied to stdscr. These
+ instructions will work on any window, providing you change the
+ function names and parameters as mentioned above.
+
+ Here is a sample program to motivate the discussion:
+
+#include <curses.h>
+#include <signal.h>
+
+static void finish(int sig);
+
+main(int argc, char *argv[])
+{
+ /* initialize your non-curses data structures here */
+
+ (void) signal(SIGINT, finish); /* arrange interrupts to terminate */
+
+ (void) initscr(); /* initialize the curses library */
+ keypad(stdscr, TRUE); /* enable keyboard mapping */
+ (void) nonl(); /* tell curses not to do NL->CR/NL on output */
+ (void) cbreak(); /* take input chars one at a time, no wait for \n */
+ (void) noecho(); /* don't echo input */
+
+ if (has_colors())
+ {
+ start_color();
+
+ /*
+ * Simple color assignment, often all we need.
+ */
+ init_pair(COLOR_BLACK, COLOR_BLACK, COLOR_BLACK);
+ init_pair(COLOR_GREEN, COLOR_GREEN, COLOR_BLACK);
+ init_pair(COLOR_RED, COLOR_RED, COLOR_BLACK);
+ init_pair(COLOR_CYAN, COLOR_CYAN, COLOR_BLACK);
+ init_pair(COLOR_WHITE, COLOR_WHITE, COLOR_BLACK);
+ init_pair(COLOR_MAGENTA, COLOR_MAGENTA, COLOR_BLACK);
+ init_pair(COLOR_BLUE, COLOR_BLUE, COLOR_BLACK);
+ init_pair(COLOR_YELLOW, COLOR_YELLOW, COLOR_BLACK);
+ }
+
+ for (;;)
+ {
+ int c = getch(); /* refresh, accept single keystroke of input */
+
+ /* process the command keystroke */
+ }
+
+ finish(0); /* we're done */
+}
+
+static void finish(int sig)
+{
+ endwin();
+
+ /* do your non-curses wrapup here */
+
+ exit(0);
+}
+
+ Starting up
+
+ In order to use the screen package, the routines must know about
+ terminal characteristics, and the space for curscr and stdscr must be
+ allocated. These function initscr() does both these things. Since it
+ must allocate space for the windows, it can overflow memory when
+ attempting to do so. On the rare occasions this happens, initscr()
+ will terminate the program with an error message. initscr() must
+ always be called before any of the routines which affect windows are
+ used. If it is not, the program will core dump as soon as either
+ curscr or stdscr are referenced. However, it is usually best to wait
+ to call it until after you are sure you will need it, like after
+ checking for startup errors. Terminal status changing routines like
+ nl() and cbreak() should be called after initscr().
+
+ Once the screen windows have been allocated, you can set them up for
+ your program. If you want to, say, allow a screen to scroll, use
+ scrollok(). If you want the cursor to be left in place after the last
+ change, use leaveok(). If this isn't done, refresh() will move the
+ cursor to the window's current (y, x) coordinates after updating it.
+
+ You can create new windows of your own using the functions newwin(),
+ derwin(), and subwin(). The routine delwin() will allow you to get rid
+ of old windows. All the options described above can be applied to any
+ window.
+
+ Output
+
+ Now that we have set things up, we will want to actually update the
+ terminal. The basic functions used to change what will go on a window
+ are addch() and move(). addch() adds a character at the current (y, x)
+ coordinates. move() changes the current (y, x) coordinates to whatever
+ you want them to be. It returns ERR if you try to move off the window.
+ As mentioned above, you can combine the two into mvaddch() to do both
+ things at once.
+
+ The other output functions, such as addstr() and printw(), all call
+ addch() to add characters to the window.
+
+ After you have put on the window what you want there, when you want
+ the portion of the terminal covered by the window to be made to look
+ like it, you must call refresh(). In order to optimize finding
+ changes, refresh() assumes that any part of the window not changed
+ since the last refresh() of that window has not been changed on the
+ terminal, i.e., that you have not refreshed a portion of the terminal
+ with an overlapping window. If this is not the case, the routine
+ touchwin() is provided to make it look like the entire window has been
+ changed, thus making refresh() check the whole subsection of the
+ terminal for changes.
+
+ If you call wrefresh() with curscr as its argument, it will make the
+ screen look like curscr thinks it looks like. This is useful for
+ implementing a command which would redraw the screen in case it get
+ messed up.
+
+ Input
+
+ The complementary function to addch() is getch() which, if echo is
+ set, will call addch() to echo the character. Since the screen package
+ needs to know what is on the terminal at all times, if characters are
+ to be echoed, the tty must be in raw or cbreak mode. Since initially
+ the terminal has echoing enabled and is in ordinary ``cooked'' mode,
+ one or the other has to changed before calling getch(); otherwise, the
+ program's output will be unpredictable.
+
+ When you need to accept line-oriented input in a window, the functions
+ wgetstr() and friends are available. There is even a wscanw() function
+ that can do scanf()(3)-style multi-field parsing on window input.
+ These pseudo-line-oriented functions turn on echoing while they
+ execute.
+
+ The example code above uses the call keypad(stdscr, TRUE) to enable
+ support for function-key mapping. With this feature, the getch() code
+ watches the input stream for character sequences that correspond to
+ arrow and function keys. These sequences are returned as
+ pseudo-character values. The #define values returned are listed in the
+ curses.h The mapping from sequences to #define values is determined by
+ key_ capabilities in the terminal's terminfo entry.
+
+ Using Forms Characters
+
+ The addch() function (and some others, including box() and border())
+ can accept some pseudo-character arguments which are specially defined
+ by ncurses. These are #define values set up in the curses.h header;
+ see there for a complete list (look for the prefix ACS_).
+
+ The most useful of the ACS defines are the forms-drawing characters.
+ You can use these to draw boxes and simple graphs on the screen. If
+ the terminal does not have such characters, curses.h will map them to
+ a recognizable (though ugly) set of ASCII defaults.
+
+ Character Attributes and Color
+
+ The ncurses package supports screen highlights including standout,
+ reverse-video, underline, and blink. It also supports color, which is
+ treated as another kind of highlight.
+
+ Highlights are encoded, internally, as high bits of the
+ pseudo-character type (chtype) that curses.h uses to represent the
+ contents of a screen cell. See the curses.h header file for a complete
+ list of highlight mask values (look for the prefix A_).
+
+ There are two ways to make highlights. One is to logical-or the value
+ of the highlights you want into the character argument of an addch()
+ call, or any other output call that takes a chtype argument.
+
+ The other is to set the current-highlight value. This is logical-or'ed
+ with any highlight you specify the first way. You do this with the
+ functions attron(), attroff(), and attrset(); see the manual pages for
+ details. Color is a special kind of highlight. The package actually
+ thinks in terms of color pairs, combinations of foreground and
+ background colors. The sample code above sets up eight color pairs,
+ all of the guaranteed-available colors on black. Note that each color
+ pair is, in effect, given the name of its foreground color. Any other
+ range of eight non-conflicting values could have been used as the
+ first arguments of the init_pair() values.
+
+ Once you've done an init_pair() that creates color-pair N, you can use
+ COLOR_PAIR(N) as a highlight that invokes that particular color
+ combination. Note that COLOR_PAIR(N), for constant N, is itself a
+ compile-time constant and can be used in initializers.
+
+ Mouse Interfacing
+
+ The ncurses library also provides a mouse interface.
+
+ NOTE: this facility is specific to ncurses, it is not part of
+ either the XSI Curses standard, nor of System V Release 4, nor BSD
+ curses. System V Release 4 curses contains code with similar
+ interface definitions, however it is not documented. Other than by
+ disassembling the library, we have no way to determine exactly how
+ that mouse code works. Thus, we recommend that you wrap
+ mouse-related code in an #ifdef using the feature macro
+ NCURSES_MOUSE_VERSION so it will not be compiled and linked on
+ non-ncurses systems.
+
+ Presently, mouse event reporting works in the following environments:
+ * xterm and similar programs such as rxvt.
+ * Linux console, when configured with gpm(1), Alessandro Rubini's
+ mouse server.
+ * OS/2 EMX
+
+ The mouse interface is very simple. To activate it, you use the
+ function mousemask(), passing it as first argument a bit-mask that
+ specifies what kinds of events you want your program to be able to
+ see. It will return the bit-mask of events that actually become
+ visible, which may differ from the argument if the mouse device is not
+ capable of reporting some of the event types you specify.
+
+ Once the mouse is active, your application's command loop should watch
+ for a return value of KEY_MOUSE from wgetch(). When you see this, a
+ mouse event report has been queued. To pick it off the queue, use the
+ function getmouse() (you must do this before the next wgetch(),
+ otherwise another mouse event might come in and make the first one
+ inaccessible).
+
+ Each call to getmouse() fills a structure (the address of which you'll
+ pass it) with mouse event data. The event data includes zero-origin,
+ screen-relative character-cell coordinates of the mouse pointer. It
+ also includes an event mask. Bits in this mask will be set,
+ corresponding to the event type being reported.
+
+ The mouse structure contains two additional fields which may be
+ significant in the future as ncurses interfaces to new kinds of
+ pointing device. In addition to x and y coordinates, there is a slot
+ for a z coordinate; this might be useful with touch-screens that can
+ return a pressure or duration parameter. There is also a device ID
+ field, which could be used to distinguish between multiple pointing
+ devices.
+
+ The class of visible events may be changed at any time via
+ mousemask(). Events that can be reported include presses, releases,
+ single-, double- and triple-clicks (you can set the maximum
+ button-down time for clicks). If you don't make clicks visible, they
+ will be reported as press-release pairs. In some environments, the
+ event mask may include bits reporting the state of shift, alt, and
+ ctrl keys on the keyboard during the event.
+
+ A function to check whether a mouse event fell within a given window
+ is also supplied. You can use this to see whether a given window
+ should consider a mouse event relevant to it.
+
+ Because mouse event reporting will not be available in all
+ environments, it would be unwise to build ncurses applications that
+ require the use of a mouse. Rather, you should use the mouse as a
+ shortcut for point-and-shoot commands your application would normally
+ accept from the keyboard. Two of the test games in the ncurses
+ distribution (bs and knight) contain code that illustrates how this
+ can be done.
+
+ See the manual page curs_mouse(3X) for full details of the
+ mouse-interface functions.
+
+ Finishing Up
+
+ In order to clean up after the ncurses routines, the routine endwin()
+ is provided. It restores tty modes to what they were when initscr()
+ was first called, and moves the cursor down to the lower-left corner.
+ Thus, anytime after the call to initscr, endwin() should be called
+ before exiting.
+
+Function Descriptions
+
+ We describe the detailed behavior of some important curses functions
+ here, as a supplement to the manual page descriptions.
+
+ Initialization and Wrapup
+
+ initscr()
+ The first function called should almost always be initscr().
+ This will determine the terminal type and initialize curses
+ data structures. initscr() also arranges that the first call to
+ refresh() will clear the screen. If an error occurs a message
+ is written to standard error and the program exits. Otherwise
+ it returns a pointer to stdscr. A few functions may be called
+ before initscr (slk_init(), filter(), ripofflines(), use_env(),
+ and, if you are using multiple terminals, newterm().)
+
+ endwin()
+ Your program should always call endwin() before exiting or
+ shelling out of the program. This function will restore tty
+ modes, move the cursor to the lower left corner of the screen,
+ reset the terminal into the proper non-visual mode. Calling
+ refresh() or doupdate() after a temporary escape from the
+ program will restore the ncurses screen from before the escape.
+
+ newterm(type, ofp, ifp)
+ A program which outputs to more than one terminal should use
+ newterm() instead of initscr(). newterm() should be called once
+ for each terminal. It returns a variable of type SCREEN * which
+ should be saved as a reference to that terminal. The arguments
+ are the type of the terminal (a string) and FILE pointers for
+ the output and input of the terminal. If type is NULL then the
+ environment variable $TERM is used. endwin() should called once
+ at wrapup time for each terminal opened using this function.
+
+ set_term(new)
+ This function is used to switch to a different terminal
+ previously opened by newterm(). The screen reference for the
+ new terminal is passed as the parameter. The previous terminal
+ is returned by the function. All other calls affect only the
+ current terminal.
+
+ delscreen(sp)
+ The inverse of newterm(); deallocates the data structures
+ associated with a given SCREEN reference.
+
+ Causing Output to the Terminal
+
+ refresh() and wrefresh(win)
+ These functions must be called to actually get any output on
+ the terminal, as other routines merely manipulate data
+ structures. wrefresh() copies the named window to the physical
+ terminal screen, taking into account what is already there in
+ order to do optimizations. refresh() does a refresh of
+ stdscr(). Unless leaveok() has been enabled, the physical
+ cursor of the terminal is left at the location of the window's
+ cursor.
+
+ doupdate() and wnoutrefresh(win)
+ These two functions allow multiple updates with more efficiency
+ than wrefresh. To use them, it is important to understand how
+ curses works. In addition to all the window structures, curses
+ keeps two data structures representing the terminal screen: a
+ physical screen, describing what is actually on the screen, and
+ a virtual screen, describing what the programmer wants to have
+ on the screen. wrefresh works by first copying the named window
+ to the virtual screen (wnoutrefresh()), and then calling the
+ routine to update the screen (doupdate()). If the programmer
+ wishes to output several windows at once, a series of calls to
+ wrefresh will result in alternating calls to wnoutrefresh() and
+ doupdate(), causing several bursts of output to the screen. By
+ calling wnoutrefresh() for each window, it is then possible to
+ call doupdate() once, resulting in only one burst of output,
+ with fewer total characters transmitted (this also avoids a
+ visually annoying flicker at each update).
+
+ Low-Level Capability Access
+
+ setupterm(term, filenum, errret)
+ This routine is called to initialize a terminal's description,
+ without setting up the curses screen structures or changing the
+ tty-driver mode bits. term is the character string representing
+ the name of the terminal being used. filenum is the UNIX file
+ descriptor of the terminal to be used for output. errret is a
+ pointer to an integer, in which a success or failure indication
+ is returned. The values returned can be 1 (all is well), 0 (no
+ such terminal), or -1 (some problem locating the terminfo
+ database).
+
+ The value of term can be given as NULL, which will cause the
+ value of TERM in the environment to be used. The errret pointer
+ can also be given as NULL, meaning no error code is wanted. If
+ errret is defaulted, and something goes wrong, setupterm() will
+ print an appropriate error message and exit, rather than
+ returning. Thus, a simple program can call setupterm(0, 1, 0)
+ and not worry about initialization errors.
+
+ After the call to setupterm(), the global variable cur_term is
+ set to point to the current structure of terminal capabilities.
+ By calling setupterm() for each terminal, and saving and
+ restoring cur_term, it is possible for a program to use two or
+ more terminals at once. Setupterm() also stores the names
+ section of the terminal description in the global character
+ array ttytype[]. Subsequent calls to setupterm() will overwrite
+ this array, so you'll have to save it yourself if need be.
+
+ Debugging
+
+ NOTE: These functions are not part of the standard curses API!
+
+ trace()
+ This function can be used to explicitly set a trace level. If
+ the trace level is nonzero, execution of your program will
+ generate a file called `trace' in the current working directory
+ containing a report on the library's actions. Higher trace
+ levels enable more detailed (and verbose) reporting -- see
+ comments attached to TRACE_ defines in the curses.h file for
+ details. (It is also possible to set a trace level by assigning
+ a trace level value to the environment variable NCURSES_TRACE).
+
+ _tracef()
+ This function can be used to output your own debugging
+ information. It is only available only if you link with
+ -lncurses_g. It can be used the same way as printf(), only it
+ outputs a newline after the end of arguments. The output goes
+ to a file called trace in the current directory.
+
+ Trace logs can be difficult to interpret due to the sheer volume of
+ data dumped in them. There is a script called tracemunch included with
+ the ncurses distribution that can alleviate this problem somewhat; it
+ compacts long sequences of similar operations into more succinct
+ single-line pseudo-operations. These pseudo-ops can be distinguished
+ by the fact that they are named in capital letters.
+
+Hints, Tips, and Tricks
+
+ The ncurses manual pages are a complete reference for this library. In
+ the remainder of this document, we discuss various useful methods that
+ may not be obvious from the manual page descriptions.
+
+ Some Notes of Caution
+
+ If you find yourself thinking you need to use noraw() or nocbreak(),
+ think again and move carefully. It's probably better design to use
+ getstr() or one of its relatives to simulate cooked mode. The noraw()
+ and nocbreak() functions try to restore cooked mode, but they may end
+ up clobbering some control bits set before you started your
+ application. Also, they have always been poorly documented, and are
+ likely to hurt your application's usability with other curses
+ libraries.
+
+ Bear in mind that refresh() is a synonym for wrefresh(stdscr). Don't
+ try to mix use of stdscr with use of windows declared by newwin(); a
+ refresh() call will blow them off the screen. The right way to handle
+ this is to use subwin(), or not touch stdscr at all and tile your
+ screen with declared windows which you then wnoutrefresh() somewhere
+ in your program event loop, with a single doupdate() call to trigger
+ actual repainting.
+
+ You are much less likely to run into problems if you design your
+ screen layouts to use tiled rather than overlapping windows.
+ Historically, curses support for overlapping windows has been weak,
+ fragile, and poorly documented. The ncurses library is not yet an
+ exception to this rule.
+
+ There is a panels library included in the ncurses distribution that
+ does a pretty good job of strengthening the overlapping-windows
+ facilities.
+
+ Try to avoid using the global variables LINES and COLS. Use getmaxyx()
+ on the stdscr context instead. Reason: your code may be ported to run
+ in an environment with window resizes, in which case several screens
+ could be open with different sizes.
+
+ Temporarily Leaving NCURSES Mode
+
+ Sometimes you will want to write a program that spends most of its
+ time in screen mode, but occasionally returns to ordinary `cooked'
+ mode. A common reason for this is to support shell-out. This behavior
+ is simple to arrange in ncurses.
+
+ To leave ncurses mode, call endwin() as you would if you were
+ intending to terminate the program. This will take the screen back to
+ cooked mode; you can do your shell-out. When you want to return to
+ ncurses mode, simply call refresh() or doupdate(). This will repaint
+ the screen.
+
+ There is a boolean function, isendwin(), which code can use to test
+ whether ncurses screen mode is active. It returns TRUE in the interval
+ between an endwin() call and the following refresh(), FALSE otherwise.
+
+ Here is some sample code for shellout:
+ addstr("Shelling out...");
+ def_prog_mode(); /* save current tty modes */
+ endwin(); /* restore original tty modes */
+ system("sh"); /* run shell */
+ addstr("returned.\n"); /* prepare return message */
+ refresh(); /* restore save modes, repaint screen */
+
+ Using NCURSES under XTERM
+
+ A resize operation in X sends SIGWINCH to the application running
+ under xterm. The ncurses library provides an experimental signal
+ handler, but in general does not catch this signal, because it cannot
+ know how you want the screen re-painted. You will usually have to
+ write the SIGWINCH handler yourself. Ncurses can give you some help.
+
+ The easiest way to code your SIGWINCH handler is to have it do an
+ endwin, followed by an refresh and a screen repaint you code yourself.
+ The refresh will pick up the new screen size from the xterm's
+ environment.
+
+ That is the standard way, of course (it even works with some vendor's
+ curses implementations). Its drawback is that it clears the screen to
+ reinitialize the display, and does not resize subwindows which must be
+ shrunk. Ncurses provides an extension which works better, the
+ resizeterm function. That function ensures that all windows are
+ limited to the new screen dimensions, and pads stdscr with blanks if
+ the screen is larger.
+
+ Finally, ncurses can be configured to provide its own SIGWINCH
+ handler, based on resizeterm.
+
+ Handling Multiple Terminal Screens
+
+ The initscr() function actually calls a function named newterm() to do
+ most of its work. If you are writing a program that opens multiple
+ terminals, use newterm() directly.
+
+ For each call, you will have to specify a terminal type and a pair of
+ file pointers; each call will return a screen reference, and stdscr
+ will be set to the last one allocated. You will switch between screens
+ with the set_term call. Note that you will also have to call
+ def_shell_mode and def_prog_mode on each tty yourself.
+
+ Testing for Terminal Capabilities
+
+ Sometimes you may want to write programs that test for the presence of
+ various capabilities before deciding whether to go into ncurses mode.
+ An easy way to do this is to call setupterm(), then use the functions
+ tigetflag(), tigetnum(), and tigetstr() to do your testing.
+
+ A particularly useful case of this often comes up when you want to
+ test whether a given terminal type should be treated as `smart'
+ (cursor-addressable) or `stupid'. The right way to test this is to see
+ if the return value of tigetstr("cup") is non-NULL. Alternatively, you
+ can include the term.h file and test the value of the macro
+ cursor_address.
+
+ Tuning for Speed
+
+ Use the addchstr() family of functions for fast screen-painting of
+ text when you know the text doesn't contain any control characters.
+ Try to make attribute changes infrequent on your screens. Don't use
+ the immedok() option!
+
+ Special Features of NCURSES
+
+ The wresize() function allows you to resize a window in place. The
+ associated resizeterm() function simplifies the construction of
+ SIGWINCH handlers, for resizing all windows.
+
+ The define_key() function allows you to define at runtime function-key
+ control sequences which are not in the terminal description. The
+ keyok() function allows you to temporarily enable or disable
+ interpretation of any function-key control sequence.
+
+ The use_default_colors() function allows you to construct applications
+ which can use the terminal's default foreground and background colors
+ as an additional "default" color. Several terminal emulators support
+ this feature, which is based on ISO 6429.
+
+ Ncurses supports up 16 colors, unlike SVr4 curses which defines only
+ 8. While most terminals which provide color allow only 8 colors, about
+ a quarter (including XFree86 xterm) support 16 colors.
+
+Compatibility with Older Versions
+
+ Despite our best efforts, there are some differences between ncurses
+ and the (undocumented!) behavior of older curses implementations.
+ These arise from ambiguities or omissions in the documentation of the
+ API.
+
+ Refresh of Overlapping Windows
+
+ If you define two windows A and B that overlap, and then alternately
+ scribble on and refresh them, the changes made to the overlapping
+ region under historic curses versions were often not documented
+ precisely.
+
+ To understand why this is a problem, remember that screen updates are
+ calculated between two representations of the entire display. The
+ documentation says that when you refresh a window, it is first copied
+ to to the virtual screen, and then changes are calculated to update
+ the physical screen (and applied to the terminal). But "copied to" is
+ not very specific, and subtle differences in how copying works can
+ produce different behaviors in the case where two overlapping windows
+ are each being refreshed at unpredictable intervals.
+
+ What happens to the overlapping region depends on what wnoutrefresh()
+ does with its argument -- what portions of the argument window it
+ copies to the virtual screen. Some implementations do "change copy",
+ copying down only locations in the window that have changed (or been
+ marked changed with wtouchln() and friends). Some implementations do
+ "entire copy", copying all window locations to the virtual screen
+ whether or not they have changed.
+
+ The ncurses library itself has not always been consistent on this
+ score. Due to a bug, versions 1.8.7 to 1.9.8a did entire copy.
+ Versions 1.8.6 and older, and versions 1.9.9 and newer, do change
+ copy.
+
+ For most commercial curses implementations, it is not documented and
+ not known for sure (at least not to the ncurses maintainers) whether
+ they do change copy or entire copy. We know that System V release 3
+ curses has logic in it that looks like an attempt to do change copy,
+ but the surrounding logic and data representations are sufficiently
+ complex, and our knowledge sufficiently indirect, that it's hard to
+ know whether this is reliable. It is not clear what the SVr4
+ documentation and XSI standard intend. The XSI Curses standard barely
+ mentions wnoutrefresh(); the SVr4 documents seem to be describing
+ entire-copy, but it is possible with some effort and straining to read
+ them the other way.
+
+ It might therefore be unwise to rely on either behavior in programs
+ that might have to be linked with other curses implementations.
+ Instead, you can do an explicit touchwin() before the wnoutrefresh()
+ call to guarantee an entire-contents copy anywhere.
+
+ The really clean way to handle this is to use the panels library. If,
+ when you want a screen update, you do update_panels(), it will do all
+ the necessary wnoutrfresh() calls for whatever panel stacking order
+ you have defined. Then you can do one doupdate() and there will be a
+ single burst of physical I/O that will do all your updates.
+
+ Background Erase
+
+ If you have been using a very old versions of ncurses (1.8.7 or older)
+ you may be surprised by the behavior of the erase functions. In older
+ versions, erased areas of a window were filled with a blank modified
+ by the window's current attribute (as set by wattrset(), wattron(),
+ wattroff() and friends).
+
+ In newer versions, this is not so. Instead, the attribute of erased
+ blanks is normal unless and until it is modified by the functions
+ bkgdset() or wbkgdset().
+
+ This change in behavior conforms ncurses to System V Release 4 and the
+ XSI Curses standard.
+
+XSI Curses Conformance
+
+ The ncurses library is intended to be base-level conformant with the
+ XSI Curses standard from X/Open. Many extended-level features (in
+ fact, almost all features not directly concerned with wide characters
+ and internationalization) are also supported.
+
+ One effect of XSI conformance is the change in behavior described
+ under "Background Erase -- Compatibility with Old Versions".
+
+ Also, ncurses meets the XSI requirement that every macro entry point
+ have a corresponding function which may be linked (and will be
+ prototype-checked) if the macro definition is disabled with #undef.
+
+ The Panels Library
+
+ The ncurses library by itself provides good support for screen
+ displays in which the windows are tiled (non-overlapping). In the more
+ general case that windows may overlap, you have to use a series of
+ wnoutrefresh() calls followed by a doupdate(), and be careful about
+ the order you do the window refreshes in. It has to be bottom-upwards,
+ otherwise parts of windows that should be obscured will show through.
+
+ When your interface design is such that windows may dive deeper into
+ the visibility stack or pop to the top at runtime, the resulting
+ book-keeping can be tedious and difficult to get right. Hence the
+ panels library.
+
+ The panel library first appeared in AT&T System V. The version
+ documented here is the panel code distributed with ncurses.
+
+Compiling With the Panels Library
+
+ Your panels-using modules must import the panels library declarations
+ with
+ #include <panel.h>
+
+ and must be linked explicitly with the panels library using an -lpanel
+ argument. Note that they must also link the ncurses library with
+ -lncurses. Many linkers are two-pass and will accept either order, but
+ it is still good practice to put -lpanel first and -lncurses second.
+
+Overview of Panels
+
+ A panel object is a window that is implicitly treated as part of a
+ deck including all other panel objects. The deck has an implicit
+ bottom-to-top visibility order. The panels library includes an update
+ function (analogous to refresh()) that displays all panels in the deck
+ in the proper order to resolve overlaps. The standard window, stdscr,
+ is considered below all panels.
+
+ Details on the panels functions are available in the man pages. We'll
+ just hit the highlights here.
+
+ You create a panel from a window by calling new_panel() on a window
+ pointer. It then becomes the top of the deck. The panel's window is
+ available as the value of panel_window() called with the panel pointer
+ as argument.
+
+ You can delete a panel (removing it from the deck) with del_panel.
+ This will not deallocate the associated window; you have to do that
+ yourself. You can replace a panel's window with a different window by
+ calling replace_window. The new window may be of different size; the
+ panel code will re-compute all overlaps. This operation doesn't change
+ the panel's position in the deck.
+
+ To move a panel's window, use move_panel(). The mvwin() function on
+ the panel's window isn't sufficient because it doesn't update the
+ panels library's representation of where the windows are. This
+ operation leaves the panel's depth, contents, and size unchanged.
+
+ Two functions (top_panel(), bottom_panel()) are provided for
+ rearranging the deck. The first pops its argument window to the top of
+ the deck; the second sends it to the bottom. Either operation leaves
+ the panel's screen location, contents, and size unchanged.
+
+ The function update_panels() does all the wnoutrefresh() calls needed
+ to prepare for doupdate() (which you must call yourself, afterwards).
+
+ Typically, you will want to call update_panels() and doupdate() just
+ before accepting command input, once in each cycle of interaction with
+ the user. If you call update_panels() after each and every panel
+ write, you'll generate a lot of unnecessary refresh activity and
+ screen flicker.
+
+Panels, Input, and the Standard Screen
+
+ You shouldn't mix wnoutrefresh() or wrefresh() operations with panels
+ code; this will work only if the argument window is either in the top
+ panel or unobscured by any other panels.
+
+ The stsdcr window is a special case. It is considered below all
+ panels. Because changes to panels may obscure parts of stdscr, though,
+ you should call update_panels() before doupdate() even when you only
+ change stdscr.
+
+ Note that wgetch automatically calls wrefresh. Therefore, before
+ requesting input from a panel window, you need to be sure that the
+ panel is totally unobscured.
+
+ There is presently no way to display changes to one obscured panel
+ without repainting all panels.
+
+Hiding Panels
+
+ It's possible to remove a panel from the deck temporarily; use
+ hide_panel for this. Use show_panel() to render it visible again. The
+ predicate function panel_hidden tests whether or not a panel is
+ hidden.
+
+ The panel_update code ignores hidden panels. You cannot do top_panel()
+ or bottom_panel on a hidden panel(). Other panels operations are
+ applicable.
+
+Miscellaneous Other Facilities
+
+ It's possible to navigate the deck using the functions panel_above()
+ and panel_below. Handed a panel pointer, they return the panel above
+ or below that panel. Handed NULL, they return the bottom-most or
+ top-most panel.
+
+ Every panel has an associated user pointer, not used by the panel
+ code, to which you can attach application data. See the man page
+ documentation of set_panel_userptr() and panel_userptr for details.
+
+ The Menu Library
+
+ A menu is a screen display that assists the user to choose some subset
+ of a given set of items. The menu library is a curses extension that
+ supports easy programming of menu hierarchies with a uniform but
+ flexible interface.
+
+ The menu library first appeared in AT&T System V. The version
+ documented here is the menu code distributed with ncurses.
+
+Compiling With the menu Library
+
+ Your menu-using modules must import the menu library declarations with
+ #include <menu.h>
+
+ and must be linked explicitly with the menus library using an -lmenu
+ argument. Note that they must also link the ncurses library with
+ -lncurses. Many linkers are two-pass and will accept either order, but
+ it is still good practice to put -lmenu first and -lncurses second.
+
+Overview of Menus
+
+ The menus created by this library consist of collections of items
+ including a name string part and a description string part. To make
+ menus, you create groups of these items and connect them with menu
+ frame objects.
+
+ The menu can then by posted, that is written to an associated window.
+ Actually, each menu has two associated windows; a containing window in
+ which the programmer can scribble titles or borders, and a subwindow
+ in which the menu items proper are displayed. If this subwindow is too
+ small to display all the items, it will be a scrollable viewport on
+ the collection of items.
+
+ A menu may also be unposted (that is, undisplayed), and finally freed
+ to make the storage associated with it and its items available for
+ re-use.
+
+ The general flow of control of a menu program looks like this:
+ 1. Initialize curses.
+ 2. Create the menu items, using new_item().
+ 3. Create the menu using new_menu().
+ 4. Post the menu using menu_post().
+ 5. Refresh the screen.
+ 6. Process user requests via an input loop.
+ 7. Unpost the menu using menu_unpost().
+ 8. Free the menu, using free_menu().
+ 9. Free the items using free_item().
+ 10. Terminate curses.
+
+Selecting items
+
+ Menus may be multi-valued or (the default) single-valued (see the
+ manual page menu_opts(3x) to see how to change the default). Both
+ types always have a current item.
+
+ From a single-valued menu you can read the selected value simply by
+ looking at the current item. From a multi-valued menu, you get the
+ selected set by looping through the items applying the item_value()
+ predicate function. Your menu-processing code can use the function
+ set_item_value() to flag the items in the select set.
+
+ Menu items can be made unselectable using set_item_opts() or
+ item_opts_off() with the O_SELECTABLE argument. This is the only
+ option so far defined for menus, but it is good practice to code as
+ though other option bits might be on.
+
+Menu Display
+
+ The menu library calculates a minimum display size for your window,
+ based on the following variables:
+
+ * The number and maximum length of the menu items
+ * Whether the O_ROWMAJOR option is enabled
+ * Whether display of descriptions is enabled
+ * Whatever menu format may have been set by the programmer
+ * The length of the menu mark string used for highlighting selected
+ items
+
+ The function set_menu_format() allows you to set the maximum size of
+ the viewport or menu page that will be used to display menu items. You
+ can retrieve any format associated with a menu with menu_format(). The
+ default format is rows=16, columns=1.
+
+ The actual menu page may be smaller than the format size. This depends
+ on the item number and size and whether O_ROWMAJOR is on. This option
+ (on by default) causes menu items to be displayed in a `raster-scan'
+ pattern, so that if more than one item will fit horizontally the first
+ couple of items are side-by-side in the top row. The alternative is
+ column-major display, which tries to put the first several items in
+ the first column.
+
+ As mentioned above, a menu format not large enough to allow all items
+ to fit on-screen will result in a menu display that is vertically
+ scrollable.
+
+ You can scroll it with requests to the menu driver, which will be
+ described in the section on menu input handling.
+
+ Each menu has a mark string used to visually tag selected items; see
+ the menu_mark(3x) manual page for details. The mark string length also
+ influences the menu page size.
+
+ The function scale_menu() returns the minimum display size that the
+ menu code computes from all these factors. There are other menu
+ display attributes including a select attribute, an attribute for
+ selectable items, an attribute for unselectable items, and a pad
+ character used to separate item name text from description text. These
+ have reasonable defaults which the library allows you to change (see
+ the menu_attribs(3x) manual page.
+
+Menu Windows
+
+ Each menu has, as mentioned previously, a pair of associated windows.
+ Both these windows are painted when the menu is posted and erased when
+ the menu is unposted.
+
+ The outer or frame window is not otherwise touched by the menu
+ routines. It exists so the programmer can associate a title, a border,
+ or perhaps help text with the menu and have it properly refreshed or
+ erased at post/unpost time. The inner window or subwindow is where the
+ current menu page is displayed.
+
+ By default, both windows are stdscr. You can set them with the
+ functions in menu_win(3x).
+
+ When you call menu_post(), you write the menu to its subwindow. When
+ you call menu_unpost(), you erase the subwindow, However, neither of
+ these actually modifies the screen. To do that, call wrefresh() or
+ some equivalent.
+
+Processing Menu Input
+
+ The main loop of your menu-processing code should call menu_driver()
+ repeatedly. The first argument of this routine is a menu pointer; the
+ second is a menu command code. You should write an input-fetching
+ routine that maps input characters to menu command codes, and pass its
+ output to menu_driver(). The menu command codes are fully documented
+ in menu_driver(3x).
+
+ The simplest group of command codes is REQ_NEXT_ITEM, REQ_PREV_ITEM,
+ REQ_FIRST_ITEM, REQ_LAST_ITEM, REQ_UP_ITEM, REQ_DOWN_ITEM,
+ REQ_LEFT_ITEM, REQ_RIGHT_ITEM. These change the currently selected
+ item. These requests may cause scrolling of the menu page if it only
+ partially displayed.
+
+ There are explicit requests for scrolling which also change the
+ current item (because the select location does not change, but the
+ item there does). These are REQ_SCR_DLINE, REQ_SCR_ULINE,
+ REQ_SCR_DPAGE, and REQ_SCR_UPAGE.
+
+ The REQ_TOGGLE_ITEM selects or deselects the current item. It is for
+ use in multi-valued menus; if you use it with O_ONEVALUE on, you'll
+ get an error return (E_REQUEST_DENIED).
+
+ Each menu has an associated pattern buffer. The menu_driver() logic
+ tries to accumulate printable ASCII characters passed in in that
+ buffer; when it matches a prefix of an item name, that item (or the
+ next matching item) is selected. If appending a character yields no
+ new match, that character is deleted from the pattern buffer, and
+ menu_driver() returns E_NO_MATCH.
+
+ Some requests change the pattern buffer directly: REQ_CLEAR_PATTERN,
+ REQ_BACK_PATTERN, REQ_NEXT_MATCH, REQ_PREV_MATCH. The latter two are
+ useful when pattern buffer input matches more than one item in a
+ multi-valued menu.
+
+ Each successful scroll or item navigation request clears the pattern
+ buffer. It is also possible to set the pattern buffer explicitly with
+ set_menu_pattern().
+
+ Finally, menu driver requests above the constant MAX_COMMAND are
+ considered application-specific commands. The menu_driver() code
+ ignores them and returns E_UNKNOWN_COMMAND.
+
+Miscellaneous Other Features
+
+ Various menu options can affect the processing and visual appearance
+ and input processing of menus. See menu_opts(3x) for details.
+
+ It is possible to change the current item from application code; this
+ is useful if you want to write your own navigation requests. It is
+ also possible to explicitly set the top row of the menu display. See
+ mitem_current(3x). If your application needs to change the menu
+ subwindow cursor for any reason, pos_menu_cursor() will restore it to
+ the correct location for continuing menu driver processing.
+
+ It is possible to set hooks to be called at menu initialization and
+ wrapup time, and whenever the selected item changes. See
+ menu_hook(3x).
+
+ Each item, and each menu, has an associated user pointer on which you
+ can hang application data. See mitem_userptr(3x) and menu_userptr(3x).
+
+ The Forms Library
+
+ The form library is a curses extension that supports easy programming
+ of on-screen forms for data entry and program control.
+
+ The form library first appeared in AT&T System V. The version
+ documented here is the form code distributed with ncurses.
+
+Compiling With the form Library
+
+ Your form-using modules must import the form library declarations with
+ #include <form.h>
+
+ and must be linked explicitly with the forms library using an -lform
+ argument. Note that they must also link the ncurses library with
+ -lncurses. Many linkers are two-pass and will accept either order, but
+ it is still good practice to put -lform first and -lncurses second.
+
+Overview of Forms
+
+ A form is a collection of fields; each field may be either a label
+ (explanatory text) or a data-entry location. Long forms may be
+ segmented into pages; each entry to a new page clears the screen.
+
+ To make forms, you create groups of fields and connect them with form
+ frame objects; the form library makes this relatively simple.
+
+ Once defined, a form can be posted, that is written to an associated
+ window. Actually, each form has two associated windows; a containing
+ window in which the programmer can scribble titles or borders, and a
+ subwindow in which the form fields proper are displayed.
+
+ As the form user fills out the posted form, navigation and editing
+ keys support movement between fields, editing keys support modifying
+ field, and plain text adds to or changes data in a current field. The
+ form library allows you (the forms designer) to bind each navigation
+ and editing key to any keystroke accepted by curses Fields may have
+ validation conditions on them, so that they check input data for type
+ and value. The form library supplies a rich set of pre-defined field
+ types, and makes it relatively easy to define new ones.
+
+ Once its transaction is completed (or aborted), a form may be unposted
+ (that is, undisplayed), and finally freed to make the storage
+ associated with it and its items available for re-use.
+
+ The general flow of control of a form program looks like this:
+ 1. Initialize curses.
+ 2. Create the form fields, using new_field().
+ 3. Create the form using new_form().
+ 4. Post the form using form_post().
+ 5. Refresh the screen.
+ 6. Process user requests via an input loop.
+ 7. Unpost the form using form_unpost().
+ 8. Free the form, using free_form().
+ 9. Free the fields using free_field().
+ 10. Terminate curses.
+
+ Note that this looks much like a menu program; the form library
+ handles tasks which are in many ways similar, and its interface was
+ obviously designed to resemble that of the menu library wherever
+ possible.
+
+ In forms programs, however, the `process user requests' is somewhat
+ more complicated than for menus. Besides menu-like navigation
+ operations, the menu driver loop has to support field editing and data
+ validation.
+
+Creating and Freeing Fields and Forms
+
+ The basic function for creating fields is new_field():
+
+FIELD *new_field(int height, int width, /* new field size */
+ int top, int left, /* upper left corner */
+ int offscreen, /* number of offscreen rows */
+ int nbuf); /* number of working buffers */
+
+ Menu items always occupy a single row, but forms fields may have
+ multiple rows. So new_field() requires you to specify a width and
+ height (the first two arguments, which mist both be greater than
+ zero).
+
+ You must also specify the location of the field's upper left corner on
+ the screen (the third and fourth arguments, which must be zero or
+ greater). Note that these coordinates are relative to the form
+ subwindow, which will coincide with stdscr by default but need not be
+ stdscr if you've done an explicit set_form_window() call.
+
+ The fifth argument allows you to specify a number of off-screen rows.
+ If this is zero, the entire field will always be displayed. If it is
+ nonzero, the form will be scrollable, with only one screen-full
+ (initially the top part) displayed at any given time. If you make a
+ field dynamic and grow it so it will no longer fit on the screen, the
+ form will become scrollable even if the offscreen argument was
+ initially zero.
+
+ The forms library allocates one working buffer per field; the size of
+ each buffer is ((height + offscreen)*width + 1, one character for each
+ position in the field plus a NUL terminator. The sixth argument is the
+ number of additional data buffers to allocate for the field; your
+ application can use them for its own purposes.
+
+FIELD *dup_field(FIELD *field, /* field to copy */
+ int top, int left); /* location of new copy */
+
+ The function dup_field() duplicates an existing field at a new
+ location. Size and buffering information are copied; some attribute
+ flags and status bits are not (see the form_field_new(3X) for
+ details).
+
+FIELD *link_field(FIELD *field, /* field to copy */
+ int top, int left); /* location of new copy */
+
+ The function link_field() also duplicates an existing field at a new
+ location. The difference from dup_field() is that it arranges for the
+ new field's buffer to be shared with the old one.
+
+ Besides the obvious use in making a field editable from two different
+ form pages, linked fields give you a way to hack in dynamic labels. If
+ you declare several fields linked to an original, and then make them
+ inactive, changes from the original will still be propagated to the
+ linked fields.
+
+ As with duplicated fields, linked fields have attribute bits separate
+ from the original.
+
+ As you might guess, all these field-allocations return NULL if the
+ field allocation is not possible due to an out-of-memory error or
+ out-of-bounds arguments.
+
+ To connect fields to a form, use
+
+FORM *new_form(FIELD **fields);
+
+ This function expects to see a NULL-terminated array of field
+ pointers. Said fields are connected to a newly-allocated form object;
+ its address is returned (or else NULL if the allocation fails).
+
+ Note that new_field() does not copy the pointer array into private
+ storage; if you modify the contents of the pointer array during forms
+ processing, all manner of bizarre things might happen. Also note that
+ any given field may only be connected to one form.
+
+ The functions free_field() and free_form are available to free field
+ and form objects. It is an error to attempt to free a field connected
+ to a form, but not vice-versa; thus, you will generally free your form
+ objects first.
+
+Fetching and Changing Field Attributes
+
+ Each form field has a number of location and size attributes
+ associated with it. There are other field attributes used to control
+ display and editing of the field. Some (for example, the O_STATIC bit)
+ involve sufficient complications to be covered in sections of their
+ own later on. We cover the functions used to get and set several basic
+ attributes here.
+
+ When a field is created, the attributes not specified by the new_field
+ function are copied from an invisible system default field. In
+ attribute-setting and -fetching functions, the argument NULL is taken
+ to mean this field. Changes to it persist as defaults until your forms
+ application terminates.
+
+ Fetching Size and Location Data
+
+ You can retrieve field sizes and locations through:
+
+int field_info(FIELD *field, /* field from which to fetch */
+ int *height, *int width, /* field size */
+ int *top, int *left, /* upper left corner */
+ int *offscreen, /* number of offscreen rows */
+ int *nbuf); /* number of working buffers */
+
+ This function is a sort of inverse of new_field(); instead of setting
+ size and location attributes of a new field, it fetches them from an
+ existing one.
+
+ Changing the Field Location
+
+ It is possible to move a field's location on the screen:
+
+int move_field(FIELD *field, /* field to alter */
+ int top, int left); /* new upper-left corner */
+
+ You can, of course. query the current location through field_info().
+
+ The Justification Attribute
+
+ One-line fields may be unjustified, justified right, justified left,
+ or centered. Here is how you manipulate this attribute:
+
+int set_field_just(FIELD *field, /* field to alter */
+ int justmode); /* mode to set */
+
+int field_just(FIELD *field); /* fetch mode of field */
+
+ The mode values accepted and returned by this functions are
+ preprocessor macros NO_JUSTIFICATION, JUSTIFY_RIGHT, JUSTIFY_LEFT, or
+ JUSTIFY_CENTER.
+
+ Field Display Attributes
+
+ For each field, you can set a foreground attribute for entered
+ characters, a background attribute for the entire field, and a pad
+ character for the unfilled portion of the field. You can also control
+ pagination of the form.
+
+ This group of four field attributes controls the visual appearance of
+ the field on the screen, without affecting in any way the data in the
+ field buffer.
+
+int set_field_fore(FIELD *field, /* field to alter */
+ chtype attr); /* attribute to set */
+
+chtype field_fore(FIELD *field); /* field to query */
+
+int set_field_back(FIELD *field, /* field to alter */
+ chtype attr); /* attribute to set */
+
+chtype field_back(FIELD *field); /* field to query */
+
+int set_field_pad(FIELD *field, /* field to alter */
+ int pad); /* pad character to set */
+
+chtype field_pad(FIELD *field);
+
+int set_new_page(FIELD *field, /* field to alter */
+ int flag); /* TRUE to force new page */
+
+chtype new_page(FIELD *field); /* field to query */
+
+ The attributes set and returned by the first four functions are normal
+ curses(3x) display attribute values (A_STANDOUT, A_BOLD, A_REVERSE
+ etc). The page bit of a field controls whether it is displayed at the
+ start of a new form screen.
+
+ Field Option Bits
+
+ There is also a large collection of field option bits you can set to
+ control various aspects of forms processing. You can manipulate them
+ with these functions:
+int set_field_opts(FIELD *field, /* field to alter */
+ int attr); /* attribute to set */
+
+int field_opts_on(FIELD *field, /* field to alter */
+ int attr); /* attributes to turn on */
+
+int field_opts_off(FIELD *field, /* field to alter */
+ int attr); /* attributes to turn off */
+
+int field_opts(FIELD *field); /* field to query */
+
+ By default, all options are on. Here are the available option bits:
+
+ O_VISIBLE
+ Controls whether the field is visible on the screen. Can be
+ used during form processing to hide or pop up fields depending
+ on the value of parent fields.
+
+ O_ACTIVE
+ Controls whether the field is active during forms processing
+ (i.e. visited by form navigation keys). Can be used to make
+ labels or derived fields with buffer values alterable by the
+ forms application, not the user.
+
+ O_PUBLIC
+ Controls whether data is displayed during field entry. If this
+ option is turned off on a field, the library will accept and
+ edit data in that field, but it will not be displayed and the
+ visible field cursor will not move. You can turn off the
+ O_PUBLIC bit to define password fields.
+
+ O_EDIT
+ Controls whether the field's data can be modified. When this
+ option is off, all editing requests except REQ_PREV_CHOICE and
+ REQ_NEXT_CHOICE will fail. Such read-only fields may be useful
+ for help messages.
+
+ O_WRAP
+ Controls word-wrapping in multi-line fields. Normally, when any
+ character of a (blank-separated) word reaches the end of the
+ current line, the entire word is wrapped to the next line
+ (assuming there is one). When this option is off, the word will
+ be split across the line break.
+
+ O_BLANK
+ Controls field blanking. When this option is on, entering a
+ character at the first field position erases the entire field
+ (except for the just-entered character).
+
+ O_AUTOSKIP
+ Controls automatic skip to next field when this one fills.
+ Normally, when the forms user tries to type more data into a
+ field than will fit, the editing location jumps to next field.
+ When this option is off, the user's cursor will hang at the end
+ of the field. This option is ignored in dynamic fields that
+ have not reached their size limit.
+
+ O_NULLOK
+ Controls whether validation is applied to blank fields.
+ Normally, it is not; the user can leave a field blank without
+ invoking the usual validation check on exit. If this option is
+ off on a field, exit from it will invoke a validation check.
+
+ O_PASSOK
+ Controls whether validation occurs on every exit, or only after
+ the field is modified. Normally the latter is true. Setting
+ O_PASSOK may be useful if your field's validation function may
+ change during forms processing.
+
+ O_STATIC
+ Controls whether the field is fixed to its initial dimensions.
+ If you turn this off, the field becomes dynamic and will
+ stretch to fit entered data.
+
+ A field's options cannot be changed while the field is currently
+ selected. However, options may be changed on posted fields that are
+ not current.
+
+ The option values are bit-masks and can be composed with logical-or in
+ the obvious way.
+
+Field Status
+
+ Every field has a status flag, which is set to FALSE when the field is
+ created and TRUE when the value in field buffer 0 changes. This flag
+ can be queried and set directly:
+
+int set_field_status(FIELD *field, /* field to alter */
+ int status); /* mode to set */
+
+int field_status(FIELD *field); /* fetch mode of field */
+
+ Setting this flag under program control can be useful if you use the
+ same form repeatedly, looking for modified fields each time.
+
+ Calling field_status() on a field not currently selected for input
+ will return a correct value. Calling field_status() on a field that is
+ currently selected for input may not necessarily give a correct field
+ status value, because entered data isn't necessarily copied to buffer
+ zero before the exit validation check. To guarantee that the returned
+ status value reflects reality, call field_status() either (1) in the
+ field's exit validation check routine, (2) from the field's or form's
+ initialization or termination hooks, or (3) just after a
+ REQ_VALIDATION request has been processed by the forms driver.
+
+Field User Pointer
+
+ Each field structure contains one character pointer slot that is not
+ used by the forms library. It is intended to be used by applications
+ to store private per-field data. You can manipulate it with:
+int set_field_userptr(FIELD *field, /* field to alter */
+ char *userptr); /* mode to set */
+
+char *field_userptr(FIELD *field); /* fetch mode of field */
+
+ (Properly, this user pointer field ought to have (void *) type. The
+ (char *) type is retained for System V compatibility.)
+
+ It is valid to set the user pointer of the default field (with a
+ set_field_userptr() call passed a NULL field pointer.) When a new
+ field is created, the default-field user pointer is copied to
+ initialize the new field's user pointer.
+
+Variable-Sized Fields
+
+ Normally, a field is fixed at the size specified for it at creation
+ time. If, however, you turn off its O_STATIC bit, it becomes dynamic
+ and will automatically resize itself to accommodate data as it is
+ entered. If the field has extra buffers associated with it, they will
+ grow right along with the main input buffer.
+
+ A one-line dynamic field will have a fixed height (1) but variable
+ width, scrolling horizontally to display data within the field area as
+ originally dimensioned and located. A multi-line dynamic field will
+ have a fixed width, but variable height (number of rows), scrolling
+ vertically to display data within the field area as originally
+ dimensioned and located.
+
+ Normally, a dynamic field is allowed to grow without limit. But it is
+ possible to set an upper limit on the size of a dynamic field. You do
+ it with this function:
+
+int set_max_field(FIELD *field, /* field to alter (may not be NULL) */
+ int max_size); /* upper limit on field size */
+
+ If the field is one-line, max_size is taken to be a column size limit;
+ if it is multi-line, it is taken to be a line size limit. To disable
+ any limit, use an argument of zero. The growth limit can be changed
+ whether or not the O_STATIC bit is on, but has no effect until it is.
+
+ The following properties of a field change when it becomes dynamic:
+ * If there is no growth limit, there is no final position of the
+ field; therefore O_AUTOSKIP and O_NL_OVERLOAD are ignored.
+ * Field justification will be ignored (though whatever justification
+ is set up will be retained internally and can be queried).
+ * The dup_field() and link_field() calls copy dynamic-buffer sizes.
+ If the O_STATIC option is set on one of a collection of links,
+ buffer resizing will occur only when the field is edited through
+ that link.
+ * The call field_info() will retrieve the original static size of
+ the field; use dynamic_field_info() to get the actual dynamic
+ size.
+
+Field Validation
+
+ By default, a field will accept any data that will fit in its input
+ buffer. However, it is possible to attach a validation type to a
+ field. If you do this, any attempt to leave the field while it
+ contains data that doesn't match the validation type will fail. Some
+ validation types also have a character-validity check for each time a
+ character is entered in the field.
+
+ A field's validation check (if any) is not called when
+ set_field_buffer() modifies the input buffer, nor when that buffer is
+ changed through a linked field.
+
+ The form library provides a rich set of pre-defined validation types,
+ and gives you the capability to define custom ones of your own. You
+ can examine and change field validation attributes with the following
+ functions:
+
+int set_field_type(FIELD *field, /* field to alter */
+ FIELDTYPE *ftype, /* type to associate */
+ ...); /* additional arguments*/
+
+FIELDTYPE *field_type(FIELD *field); /* field to query */
+
+ The validation type of a field is considered an attribute of the
+ field. As with other field attributes, Also, doing set_field_type()
+ with a NULL field default will change the system default for
+ validation of newly-created fields.
+
+ Here are the pre-defined validation types:
+
+ TYPE_ALPHA
+
+ This field type accepts alphabetic data; no blanks, no digits, no
+ special characters (this is checked at character-entry time). It is
+ set up with:
+
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_ALPHA, /* type to associate */
+ int width); /* maximum width of field */
+
+ The width argument sets a minimum width of data. Typically you'll want
+ to set this to the field width; if it's greater than the field width,
+ the validation check will always fail. A minimum width of zero makes
+ field completion optional.
+
+ TYPE_ALNUM
+
+ This field type accepts alphabetic data and digits; no blanks, no
+ special characters (this is checked at character-entry time). It is
+ set up with:
+
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_ALNUM, /* type to associate */
+ int width); /* maximum width of field */
+
+ The width argument sets a minimum width of data. As with TYPE_ALPHA,
+ typically you'll want to set this to the field width; if it's greater
+ than the field width, the validation check will always fail. A minimum
+ width of zero makes field completion optional.
+
+ TYPE_ENUM
+
+ This type allows you to restrict a field's values to be among a
+ specified set of string values (for example, the two-letter postal
+ codes for U.S. states). It is set up with:
+
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_ENUM, /* type to associate */
+ char **valuelist; /* list of possible values */
+ int checkcase; /* case-sensitive? */
+ int checkunique); /* must specify uniquely? */
+
+ The valuelist parameter must point at a NULL-terminated list of valid
+ strings. The checkcase argument, if true, makes comparison with the
+ string case-sensitive.
+
+ When the user exits a TYPE_ENUM field, the validation procedure tries
+ to complete the data in the buffer to a valid entry. If a complete
+ choice string has been entered, it is of course valid. But it is also
+ possible to enter a prefix of a valid string and have it completed for
+ you.
+
+ By default, if you enter such a prefix and it matches more than one
+ value in the string list, the prefix will be completed to the first
+ matching value. But the checkunique argument, if true, requires prefix
+ matches to be unique in order to be valid.
+
+ The REQ_NEXT_CHOICE and REQ_PREV_CHOICE input requests can be
+ particularly useful with these fields.
+
+ TYPE_INTEGER
+
+ This field type accepts an integer. It is set up as follows:
+
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_INTEGER, /* type to associate */
+ int padding, /* # places to zero-pad to */
+ int vmin, int vmax); /* valid range */
+
+ Valid characters consist of an optional leading minus and digits. The
+ range check is performed on exit. If the range maximum is less than or
+ equal to the minimum, the range is ignored.
+
+ If the value passes its range check, it is padded with as many leading
+ zero digits as necessary to meet the padding argument.
+
+ A TYPE_INTEGER value buffer can conveniently be interpreted with the C
+ library function atoi(3).
+
+ TYPE_NUMERIC
+
+ This field type accepts a decimal number. It is set up as follows:
+
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_NUMERIC, /* type to associate */
+ int padding, /* # places of precision */
+ double vmin, double vmax); /* valid range */
+
+ Valid characters consist of an optional leading minus and digits.
+ possibly including a decimal point. If your system supports locale's,
+ the decimal point character used must be the one defined by your
+ locale. The range check is performed on exit. If the range maximum is
+ less than or equal to the minimum, the range is ignored.
+
+ If the value passes its range check, it is padded with as many
+ trailing zero digits as necessary to meet the padding argument.
+
+ A TYPE_NUMERIC value buffer can conveniently be interpreted with the C
+ library function atof(3).
+
+ TYPE_REGEXP
+
+ This field type accepts data matching a regular expression. It is set
+ up as follows:
+
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_REGEXP, /* type to associate */
+ char *regexp); /* expression to match */
+
+ The syntax for regular expressions is that of regcomp(3). The check
+ for regular-expression match is performed on exit.
+
+Direct Field Buffer Manipulation
+
+ The chief attribute of a field is its buffer contents. When a form has
+ been completed, your application usually needs to know the state of
+ each field buffer. You can find this out with:
+
+char *field_buffer(FIELD *field, /* field to query */
+ int bufindex); /* number of buffer to query */
+
+ Normally, the state of the zero-numbered buffer for each field is set
+ by the user's editing actions on that field. It's sometimes useful to
+ be able to set the value of the zero-numbered (or some other) buffer
+ from your application:
+int set_field_buffer(FIELD *field, /* field to alter */
+ int bufindex, /* number of buffer to alter */
+ char *value); /* string value to set */
+
+ If the field is not large enough and cannot be resized to a
+ sufficiently large size to contain the specified value, the value will
+ be truncated to fit.
+
+ Calling field_buffer() with a null field pointer will raise an error.
+ Calling field_buffer() on a field not currently selected for input
+ will return a correct value. Calling field_buffer() on a field that is
+ currently selected for input may not necessarily give a correct field
+ buffer value, because entered data isn't necessarily copied to buffer
+ zero before the exit validation check. To guarantee that the returned
+ buffer value reflects on-screen reality, call field_buffer() either
+ (1) in the field's exit validation check routine, (2) from the field's
+ or form's initialization or termination hooks, or (3) just after a
+ REQ_VALIDATION request has been processed by the forms driver.
+
+Attributes of Forms
+
+ As with field attributes, form attributes inherit a default from a
+ system default form structure. These defaults can be queried or set by
+ of these functions using a form-pointer argument of NULL.
+
+ The principal attribute of a form is its field list. You can query and
+ change this list with:
+
+int set_form_fields(FORM *form, /* form to alter */
+ FIELD **fields); /* fields to connect */
+
+char *form_fields(FORM *form); /* fetch fields of form */
+
+int field_count(FORM *form); /* count connect fields */
+
+ The second argument of set_form_fields() may be a NULL-terminated
+ field pointer array like the one required by new_form(). In that case,
+ the old fields of the form are disconnected but not freed (and
+ eligible to be connected to other forms), then the new fields are
+ connected.
+
+ It may also be null, in which case the old fields are disconnected
+ (and not freed) but no new ones are connected.
+
+ The field_count() function simply counts the number of fields
+ connected to a given from. It returns -1 if the form-pointer argument
+ is NULL.
+
+Control of Form Display
+
+ In the overview section, you saw that to display a form you normally
+ start by defining its size (and fields), posting it, and refreshing
+ the screen. There is an hidden step before posting, which is the
+ association of the form with a frame window (actually, a pair of
+ windows) within which it will be displayed. By default, the forms
+ library associates every form with the full-screen window stdscr.
+
+ By making this step explicit, you can associate a form with a declared
+ frame window on your screen display. This can be useful if you want to
+ adapt the form display to different screen sizes, dynamically tile
+ forms on the screen, or use a form as part of an interface layout
+ managed by panels.
+
+ The two windows associated with each form have the same functions as
+ their analogues in the menu library. Both these windows are painted
+ when the form is posted and erased when the form is unposted.
+
+ The outer or frame window is not otherwise touched by the form
+ routines. It exists so the programmer can associate a title, a border,
+ or perhaps help text with the form and have it properly refreshed or
+ erased at post/unpost time. The inner window or subwindow is where the
+ current form page is actually displayed.
+
+ In order to declare your own frame window for a form, you'll need to
+ know the size of the form's bounding rectangle. You can get this
+ information with:
+
+int scale_form(FORM *form, /* form to query */
+ int *rows, /* form rows */
+ int *cols); /* form cols */
+
+ The form dimensions are passed back in the locations pointed to by the
+ arguments. Once you have this information, you can use it to declare
+ of windows, then use one of these functions:
+int set_form_win(FORM *form, /* form to alter */
+ WINDOW *win); /* frame window to connect */
+
+WINDOW *form_win(FORM *form); /* fetch frame window of form */
+
+int set_form_sub(FORM *form, /* form to alter */
+ WINDOW *win); /* form subwindow to connect */
+
+WINDOW *form_sub(FORM *form); /* fetch form subwindow of form */
+
+ Note that curses operations, including refresh(), on the form, should
+ be done on the frame window, not the form subwindow.
+
+ It is possible to check from your application whether all of a
+ scrollable field is actually displayed within the menu subwindow. Use
+ these functions:
+
+int data_ahead(FORM *form); /* form to be queried */
+
+int data_behind(FORM *form); /* form to be queried */
+
+ The function data_ahead() returns TRUE if (a) the current field is
+ one-line and has undisplayed data off to the right, (b) the current
+ field is multi-line and there is data off-screen below it.
+
+ The function data_behind() returns TRUE if the first (upper left hand)
+ character position is off-screen (not being displayed).
+
+ Finally, there is a function to restore the form window's cursor to
+ the value expected by the forms driver:
+
+int pos_form_cursor(FORM *) /* form to be queried */
+
+ If your application changes the form window cursor, call this function
+ before handing control back to the forms driver in order to
+ re-synchronize it.
+
+Input Processing in the Forms Driver
+
+ The function form_driver() handles virtualized input requests for form
+ navigation, editing, and validation requests, just as menu_driver does
+ for menus (see the section on menu input handling).
+
+int form_driver(FORM *form, /* form to pass input to */
+ int request); /* form request code */
+
+ Your input virtualization function needs to take input and then
+ convert it to either an alphanumeric character (which is treated as
+ data to be entered in the currently-selected field), or a forms
+ processing request.
+
+ The forms driver provides hooks (through input-validation and
+ field-termination functions) with which your application code can
+ check that the input taken by the driver matched what was expected.
+
+ Page Navigation Requests
+
+ These requests cause page-level moves through the form, triggering
+ display of a new form screen.
+
+ REQ_NEXT_PAGE
+ Move to the next form page.
+
+ REQ_PREV_PAGE
+ Move to the previous form page.
+
+ REQ_FIRST_PAGE
+ Move to the first form page.
+
+ REQ_LAST_PAGE
+ Move to the last form page.
+
+ These requests treat the list as cyclic; that is, REQ_NEXT_PAGE from
+ the last page goes to the first, and REQ_PREV_PAGE from the first page
+ goes to the last.
+
+ Inter-Field Navigation Requests
+
+ These requests handle navigation between fields on the same page.
+
+ REQ_NEXT_FIELD
+ Move to next field.
+
+ REQ_PREV_FIELD
+ Move to previous field.
+
+ REQ_FIRST_FIELD
+ Move to the first field.
+
+ REQ_LAST_FIELD
+ Move to the last field.
+
+ REQ_SNEXT_FIELD
+ Move to sorted next field.
+
+ REQ_SPREV_FIELD
+ Move to sorted previous field.
+
+ REQ_SFIRST_FIELD
+ Move to the sorted first field.
+
+ REQ_SLAST_FIELD
+ Move to the sorted last field.
+
+ REQ_LEFT_FIELD
+ Move left to field.
+
+ REQ_RIGHT_FIELD
+ Move right to field.
+
+ REQ_UP_FIELD
+ Move up to field.
+
+ REQ_DOWN_FIELD
+ Move down to field.
+
+ These requests treat the list of fields on a page as cyclic; that is,
+ REQ_NEXT_FIELD from the last field goes to the first, and
+ REQ_PREV_FIELD from the first field goes to the last. The order of the
+ fields for these (and the REQ_FIRST_FIELD and REQ_LAST_FIELD requests)
+ is simply the order of the field pointers in the form array (as set up
+ by new_form() or set_form_fields()
+
+ It is also possible to traverse the fields as if they had been sorted
+ in screen-position order, so the sequence goes left-to-right and
+ top-to-bottom. To do this, use the second group of four
+ sorted-movement requests.
+
+ Finally, it is possible to move between fields using visual directions
+ up, down, right, and left. To accomplish this, use the third group of
+ four requests. Note, however, that the position of a form for purposes
+ of these requests is its upper-left corner.
+
+ For example, suppose you have a multi-line field B, and two
+ single-line fields A and C on the same line with B, with A to the left
+ of B and C to the right of B. A REQ_MOVE_RIGHT from A will go to B
+ only if A, B, and C all share the same first line; otherwise it will
+ skip over B to C.
+
+ Intra-Field Navigation Requests
+
+ These requests drive movement of the edit cursor within the currently
+ selected field.
+
+ REQ_NEXT_CHAR
+ Move to next character.
+
+ REQ_PREV_CHAR
+ Move to previous character.
+
+ REQ_NEXT_LINE
+ Move to next line.
+
+ REQ_PREV_LINE
+ Move to previous line.
+
+ REQ_NEXT_WORD
+ Move to next word.
+
+ REQ_PREV_WORD
+ Move to previous word.
+
+ REQ_BEG_FIELD
+ Move to beginning of field.
+
+ REQ_END_FIELD
+ Move to end of field.
+
+ REQ_BEG_LINE
+ Move to beginning of line.
+
+ REQ_END_LINE
+ Move to end of line.
+
+ REQ_LEFT_CHAR
+ Move left in field.
+
+ REQ_RIGHT_CHAR
+ Move right in field.
+
+ REQ_UP_CHAR
+ Move up in field.
+
+ REQ_DOWN_CHAR
+ Move down in field.
+
+ Each word is separated from the previous and next characters by
+ whitespace. The commands to move to beginning and end of line or field
+ look for the first or last non-pad character in their ranges.
+
+ Scrolling Requests
+
+ Fields that are dynamic and have grown and fields explicitly created
+ with offscreen rows are scrollable. One-line fields scroll
+ horizontally; multi-line fields scroll vertically. Most scrolling is
+ triggered by editing and intra-field movement (the library scrolls the
+ field to keep the cursor visible). It is possible to explicitly
+ request scrolling with the following requests:
+
+ REQ_SCR_FLINE
+ Scroll vertically forward a line.
+
+ REQ_SCR_BLINE
+ Scroll vertically backward a line.
+
+ REQ_SCR_FPAGE
+ Scroll vertically forward a page.
+
+ REQ_SCR_BPAGE
+ Scroll vertically backward a page.
+
+ REQ_SCR_FHPAGE
+ Scroll vertically forward half a page.
+
+ REQ_SCR_BHPAGE
+ Scroll vertically backward half a page.
+
+ REQ_SCR_FCHAR
+ Scroll horizontally forward a character.
+
+ REQ_SCR_BCHAR
+ Scroll horizontally backward a character.
+
+ REQ_SCR_HFLINE
+ Scroll horizontally one field width forward.
+
+ REQ_SCR_HBLINE
+ Scroll horizontally one field width backward.
+
+ REQ_SCR_HFHALF
+ Scroll horizontally one half field width forward.
+
+ REQ_SCR_HBHALF
+ Scroll horizontally one half field width backward.
+
+ For scrolling purposes, a page of a field is the height of its visible
+ part.
+
+ Editing Requests
+
+ When you pass the forms driver an ASCII character, it is treated as a
+ request to add the character to the field's data buffer. Whether this
+ is an insertion or a replacement depends on the field's edit mode
+ (insertion is the default.
+
+ The following requests support editing the field and changing the edit
+ mode:
+
+ REQ_INS_MODE
+ Set insertion mode.
+
+ REQ_OVL_MODE
+ Set overlay mode.
+
+ REQ_NEW_LINE
+ New line request (see below for explanation).
+
+ REQ_INS_CHAR
+ Insert space at character location.
+
+ REQ_INS_LINE
+ Insert blank line at character location.
+
+ REQ_DEL_CHAR
+ Delete character at cursor.
+
+ REQ_DEL_PREV
+ Delete previous word at cursor.
+
+ REQ_DEL_LINE
+ Delete line at cursor.
+
+ REQ_DEL_WORD
+ Delete word at cursor.
+
+ REQ_CLR_EOL
+ Clear to end of line.
+
+ REQ_CLR_EOF
+ Clear to end of field.
+
+ REQ_CLEAR_FIELD
+ Clear entire field.
+
+ The behavior of the REQ_NEW_LINE and REQ_DEL_PREV requests is
+ complicated and partly controlled by a pair of forms options. The
+ special cases are triggered when the cursor is at the beginning of a
+ field, or on the last line of the field.
+
+ First, we consider REQ_NEW_LINE:
+
+ The normal behavior of REQ_NEW_LINE in insert mode is to break the
+ current line at the position of the edit cursor, inserting the portion
+ of the current line after the cursor as a new line following the
+ current and moving the cursor to the beginning of that new line (you
+ may think of this as inserting a newline in the field buffer).
+
+ The normal behavior of REQ_NEW_LINE in overlay mode is to clear the
+ current line from the position of the edit cursor to end of line. The
+ cursor is then moved to the beginning of the next line.
+
+ However, REQ_NEW_LINE at the beginning of a field, or on the last line
+ of a field, instead does a REQ_NEXT_FIELD. O_NL_OVERLOAD option is
+ off, this special action is disabled.
+
+ Now, let us consider REQ_DEL_PREV:
+
+ The normal behavior of REQ_DEL_PREV is to delete the previous
+ character. If insert mode is on, and the cursor is at the start of a
+ line, and the text on that line will fit on the previous one, it
+ instead appends the contents of the current line to the previous one
+ and deletes the current line (you may think of this as deleting a
+ newline from the field buffer).
+
+ However, REQ_DEL_PREV at the beginning of a field is instead treated
+ as a REQ_PREV_FIELD.
+
+ If the O_BS_OVERLOAD option is off, this special action is disabled
+ and the forms driver just returns E_REQUEST_DENIED.
+
+ See Form Options for discussion of how to set and clear the overload
+ options.
+
+ Order Requests
+
+ If the type of your field is ordered, and has associated functions for
+ getting the next and previous values of the type from a given value,
+ there are requests that can fetch that value into the field buffer:
+
+ REQ_NEXT_CHOICE
+ Place the successor value of the current value in the buffer.
+
+ REQ_PREV_CHOICE
+ Place the predecessor value of the current value in the buffer.
+
+ Of the built-in field types, only TYPE_ENUM has built-in successor and
+ predecessor functions. When you define a field type of your own (see
+ Custom Validation Types), you can associate our own ordering
+ functions.
+
+ Application Commands
+
+ Form requests are represented as integers above the curses value
+ greater than KEY_MAX and less than or equal to the constant
+ MAX_COMMAND. If your input-virtualization routine returns a value
+ above MAX_COMMAND, the forms driver will ignore it.
+
+Field Change Hooks
+
+ It is possible to set function hooks to be executed whenever the
+ current field or form changes. Here are the functions that support
+ this:
+
+typedef void (*HOOK)(); /* pointer to function returning void */
+
+int set_form_init(FORM *form, /* form to alter */
+ HOOK hook); /* initialization hook */
+
+HOOK form_init(FORM *form); /* form to query */
+
+int set_form_term(FORM *form, /* form to alter */
+ HOOK hook); /* termination hook */
+
+HOOK form_term(FORM *form); /* form to query */
+
+int set_field_init(FORM *form, /* form to alter */
+ HOOK hook); /* initialization hook */
+
+HOOK field_init(FORM *form); /* form to query */
+
+int set_field_term(FORM *form, /* form to alter */
+ HOOK hook); /* termination hook */
+
+HOOK field_term(FORM *form); /* form to query */
+
+ These functions allow you to either set or query four different hooks.
+ In each of the set functions, the second argument should be the
+ address of a hook function. These functions differ only in the timing
+ of the hook call.
+
+ form_init
+ This hook is called when the form is posted; also, just after
+ each page change operation.
+
+ field_init
+ This hook is called when the form is posted; also, just after
+ each field change
+
+ field_term
+ This hook is called just after field validation; that is, just
+ before the field is altered. It is also called when the form is
+ unposted.
+
+ form_term
+ This hook is called when the form is unposted; also, just
+ before each page change operation.
+
+ Calls to these hooks may be triggered
+ 1. When user editing requests are processed by the forms driver
+ 2. When the current page is changed by set_current_field() call
+ 3. When the current field is changed by a set_form_page() call
+
+ See Field Change Commands for discussion of the latter two cases.
+
+ You can set a default hook for all fields by passing one of the set
+ functions a NULL first argument.
+
+ You can disable any of these hooks by (re)setting them to NULL, the
+ default value.
+
+Field Change Commands
+
+ Normally, navigation through the form will be driven by the user's
+ input requests. But sometimes it is useful to be able to move the
+ focus for editing and viewing under control of your application, or
+ ask which field it currently is in. The following functions help you
+ accomplish this:
+
+int set_current_field(FORM *form, /* form to alter */
+ FIELD *field); /* field to shift to */
+
+FIELD *current_field(FORM *form); /* form to query */
+
+int field_index(FORM *form, /* form to query */
+ FIELD *field); /* field to get index of */
+
+ The function field_index() returns the index of the given field in the
+ given form's field array (the array passed to new_form() or
+ set_form_fields()).
+
+ The initial current field of a form is the first active field on the
+ first page. The function set_form_fields() resets this.
+
+ It is also possible to move around by pages.
+
+int set_form_page(FORM *form, /* form to alter */
+ int page); /* page to go to (0-origin) */
+
+int form_page(FORM *form); /* return form's current page */
+
+ The initial page of a newly-created form is 0. The function
+ set_form_fields() resets this.
+
+Form Options
+
+ Like fields, forms may have control option bits. They can be changed
+ or queried with these functions:
+
+int set_form_opts(FORM *form, /* form to alter */
+ int attr); /* attribute to set */
+
+int form_opts_on(FORM *form, /* form to alter */
+ int attr); /* attributes to turn on */
+
+int form_opts_off(FORM *form, /* form to alter */
+ int attr); /* attributes to turn off */
+
+int form_opts(FORM *form); /* form to query */
+
+ By default, all options are on. Here are the available option bits:
+
+ O_NL_OVERLOAD
+ Enable overloading of REQ_NEW_LINE as described in Editing
+ Requests. The value of this option is ignored on dynamic fields
+ that have not reached their size limit; these have no last
+ line, so the circumstances for triggering a REQ_NEXT_FIELD
+ never arise.
+
+ O_BS_OVERLOAD
+ Enable overloading of REQ_DEL_PREV as described in Editing
+ Requests.
+
+ The option values are bit-masks and can be composed with logical-or in
+ the obvious way.
+
+Custom Validation Types
+
+ The form library gives you the capability to define custom validation
+ types of your own. Further, the optional additional arguments of
+ set_field_type effectively allow you to parameterize validation types.
+ Most of the complications in the validation-type interface have to do
+ with the handling of the additional arguments within custom validation
+ functions.
+
+ Union Types
+
+ The simplest way to create a custom data type is to compose it from
+ two preexisting ones:
+
+FIELD *link_fieldtype(FIELDTYPE *type1,
+ FIELDTYPE *type2);
+
+ This function creates a field type that will accept any of the values
+ legal for either of its argument field types (which may be either
+ predefined or programmer-defined). If a set_field_type() call later
+ requires arguments, the new composite type expects all arguments for
+ the first type, than all arguments for the second. Order functions
+ (see Order Requests) associated with the component types will work on
+ the composite; what it does is check the validation function for the
+ first type, then for the second, to figure what type the buffer
+ contents should be treated as.
+
+ New Field Types
+
+ To create a field type from scratch, you need to specify one or both
+ of the following things:
+
+ * A character-validation function, to check each character as it is
+ entered.
+ * A field-validation function to be applied on exit from the field.
+
+ Here's how you do that:
+
+typedef int (*HOOK)(); /* pointer to function returning int */
+
+FIELDTYPE *new_fieldtype(HOOK f_validate, /* field validator */
+ HOOK c_validate) /* character validator */
+
+
+int free_fieldtype(FIELDTYPE *ftype); /* type to free */
+
+ At least one of the arguments of new_fieldtype() must be non-NULL. The
+ forms driver will automatically call the new type's validation
+ functions at appropriate points in processing a field of the new type.
+
+ The function free_fieldtype() deallocates the argument fieldtype,
+ freeing all storage associated with it.
+
+ Normally, a field validator is called when the user attempts to leave
+ the field. Its first argument is a field pointer, from which it can
+ get to field buffer 0 and test it. If the function returns TRUE, the
+ operation succeeds; if it returns FALSE, the edit cursor stays in the
+ field.
+
+ A character validator gets the character passed in as a first
+ argument. It too should return TRUE if the character is valid, FALSE
+ otherwise.
+
+ Validation Function Arguments
+
+ Your field- and character- validation functions will be passed a
+ second argument as well. This second argument is the address of a
+ structure (which we'll call a pile) built from any of the
+ field-type-specific arguments passed to set_field_type(). If no such
+ arguments are defined for the field type, this pile pointer argument
+ will be NULL.
+
+ In order to arrange for such arguments to be passed to your validation
+ functions, you must associate a small set of storage-management
+ functions with the type. The forms driver will use these to synthesize
+ a pile from the trailing arguments of each set_field_type() argument,
+ and a pointer to the pile will be passed to the validation functions.
+
+ Here is how you make the association:
+
+typedef char *(*PTRHOOK)(); /* pointer to function returning (char *) */
+typedef void (*VOIDHOOK)(); /* pointer to function returning void */
+
+int set_fieldtype_arg(FIELDTYPE *type, /* type to alter */
+ PTRHOOK make_str, /* make structure from args */
+ PTRHOOK copy_str, /* make copy of structure */
+ VOIDHOOK free_str); /* free structure storage */
+
+ Here is how the storage-management hooks are used:
+
+ make_str
+ This function is called by set_field_type(). It gets one
+ argument, a va_list of the type-specific arguments passed to
+ set_field_type(). It is expected to return a pile pointer to a
+ data structure that encapsulates those arguments.
+
+ copy_str
+ This function is called by form library functions that allocate
+ new field instances. It is expected to take a pile pointer,
+ copy the pile to allocated storage, and return the address of
+ the pile copy.
+
+ free_str
+ This function is called by field- and type-deallocation
+ routines in the library. It takes a pile pointer argument, and
+ is expected to free the storage of that pile.
+
+ The make_str and copy_str functions may return NULL to signal
+ allocation failure. The library routines will that call them will
+ return error indication when this happens. Thus, your validation
+ functions should never see a NULL file pointer and need not check
+ specially for it.
+
+ Order Functions For Custom Types
+
+ Some custom field types are simply ordered in the same well-defined
+ way that TYPE_ENUM is. For such types, it is possible to define
+ successor and predecessor functions to support the REQ_NEXT_CHOICE and
+ REQ_PREV_CHOICE requests. Here's how:
+
+typedef int (*INTHOOK)(); /* pointer to function returning int */
+
+int set_fieldtype_arg(FIELDTYPE *type, /* type to alter */
+ INTHOOK succ, /* get successor value */
+ INTHOOK pred); /* get predecessor value */
+
+ The successor and predecessor arguments will each be passed two
+ arguments; a field pointer, and a pile pointer (as for the validation
+ functions). They are expected to use the function field_buffer() to
+ read the current value, and set_field_buffer() on buffer 0 to set the
+ next or previous value. Either hook may return TRUE to indicate
+ success (a legal next or previous value was set) or FALSE to indicate
+ failure.
+
+ Avoiding Problems
+
+ The interface for defining custom types is complicated and tricky.
+ Rather than attempting to create a custom type entirely from scratch,
+ you should start by studying the library source code for whichever of
+ the pre-defined types seems to be closest to what you want.
+
+ Use that code as a model, and evolve it towards what you really want.
+ You will avoid many problems and annoyances that way. The code in the
+ ncurses library has been specifically exempted from the package
+ copyright to support this.
+
+ If your custom type defines order functions, have do something
+ intuitive with a blank field. A useful convention is to make the
+ successor of a blank field the types minimum value, and its
+ predecessor the maximum.
diff --git a/contrib/ncurses/misc/ncurses-intro.html b/contrib/ncurses/misc/ncurses-intro.html
new file mode 100644
index 000000000000..d01c65e6e52d
--- /dev/null
+++ b/contrib/ncurses/misc/ncurses-intro.html
@@ -0,0 +1,2682 @@
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
+<!--
+ $Id: ncurses-intro.html,v 1.31 1999/05/16 17:02:31 juergen Exp $
+-->
+<HTML>
+<HEAD>
+<TITLE>Writing Programs with NCURSES</TITLE>
+<link rev="made" href="mailto:bugs-ncurses@gnu.org">
+</HEAD>
+<BODY>
+
+<H1>Writing Programs with NCURSES</H1>
+
+<BLOCKQUOTE>
+by Eric S. Raymond and Zeyd M. Ben-Halim<BR>
+updates since release 1.9.9e by Thomas Dickey
+</BLOCKQUOTE>
+
+<H1>Contents</H1>
+<UL>
+<LI><A HREF="#introduction">Introduction</A>
+<UL>
+<LI><A HREF="#history">A Brief History of Curses</A>
+<LI><A HREF="#scope">Scope of This Document</A>
+<LI><A HREF="#terminology">Terminology</A>
+</UL>
+<LI><A HREF="#curses">The Curses Library</A>
+<UL>
+<LI><A HREF="#overview">An Overview of Curses</A>
+<UL>
+<LI><A HREF="#compiling">Compiling Programs using Curses</A>
+<LI><A HREF="#updating">Updating the Screen</A>
+<LI><A HREF="#stdscr">Standard Windows and Function Naming Conventions</A>
+<LI><A HREF="#variables">Variables</A>
+</UL>
+<LI><A HREF="#using">Using the Library</A>
+<UL>
+<LI><A HREF="#starting">Starting up</A>
+<LI><A HREF="#output">Output</A>
+<LI><A HREF="#input">Input</A>
+<LI><A HREF="#formschars">Using Forms Characters</A>
+<LI><A HREF="#attributes">Character Attributes and Color</A>
+<LI><A HREF="#mouse">Mouse Interfacing</A>
+<LI><A HREF="#finishing">Finishing Up</A>
+</UL>
+<LI><A HREF="#functions">Function Descriptions</A>
+<UL>
+<LI><A HREF="#init">Initialization and Wrapup</A>
+<LI><A HREF="#flush">Causing Output to the Terminal</A>
+<LI><A HREF="#lowlevel">Low-Level Capability Access</A>
+<LI><A HREF="#debugging">Debugging</A>
+</UL>
+<LI><A HREF="#hints">Hints, Tips, and Tricks</A>
+<UL>
+<LI><A HREF="#caution">Some Notes of Caution</A>
+<LI><A HREF="#leaving">Temporarily Leaving ncurses Mode</A>
+<LI><A HREF="#xterm">Using <CODE>ncurses</CODE> under <CODE>xterm</CODE></A>
+<LI><A HREF="#screens">Handling Multiple Terminal Screens</A>
+<LI><A HREF="#testing">Testing for Terminal Capabilities</A>
+<LI><A HREF="#tuning">Tuning for Speed</A>
+<LI><A HREF="#special">Special Features of <CODE>ncurses</CODE></A>
+</UL>
+<LI><A HREF="#compat">Compatibility with Older Versions</A>
+<UL>
+<LI><A HREF="#refbug">Refresh of Overlapping Windows</A>
+<LI><A HREF="#backbug">Background Erase</A>
+</UL>
+<LI><A HREF="#xsifuncs">XSI Curses Conformance</A>
+</UL>
+<LI><A HREF="#panels">The Panels Library</A>
+<UL>
+<LI><A HREF="#pcompile">Compiling With the Panels Library</A>
+<LI><A HREF="#poverview">Overview of Panels</A>
+<LI><A HREF="#pstdscr">Panels, Input, and the Standard Screen</A>
+<LI><A HREF="#hiding">Hiding Panels</A>
+<LI><A HREF="#pmisc">Miscellaneous Other Facilities</A>
+</UL>
+<LI><A HREF="#menu">The Menu Library</A>
+<UL>
+<LI><A HREF="#mcompile">Compiling with the menu Library</A>
+<LI><A HREF="#moverview">Overview of Menus</A>
+<LI><A HREF="#mselect">Selecting items</A>
+<LI><A HREF="#mdisplay">Menu Display</A>
+<LI><A HREF="#mwindows">Menu Windows</A>
+<LI><A HREF="#minput">Processing Menu Input</A>
+<LI><A HREF="#mmisc">Miscellaneous Other Features</A>
+</UL>
+<LI><A HREF="#form">The Forms Library</A>
+<UL>
+<LI><A HREF="#fcompile">Compiling with the forms Library</A>
+<LI><A HREF="#foverview">Overview of Forms</A>
+<LI><A HREF="#fcreate">Creating and Freeing Fields and Forms</A>
+<LI><A HREF="#fattributes">Fetching and Changing Field Attributes</A>
+<UL>
+<LI><A HREF="#fsizes">Fetching Size and Location Data</A>
+<LI><A HREF="#flocation">Changing the Field Location</A>
+<LI><A HREF="#fjust">The Justification Attribute</A>
+<LI><A HREF="#fdispatts">Field Display Attributes</A>
+<LI><A HREF="#foptions">Field Option Bits</A>
+<LI><A HREF="#fstatus">Field Status</A>
+<LI><A HREF="#fuser">Field User Pointer</A>
+</UL>
+<LI><A HREF="#fdynamic">Variable-Sized Fields</A>
+<LI><A HREF="#fvalidation">Field Validation</A>
+<UL>
+<LI><A HREF="#ftype_alpha">TYPE_ALPHA</A>
+<LI><A HREF="#ftype_alnum">TYPE_ALNUM</A>
+<LI><A HREF="#ftype_enum">TYPE_ENUM</A>
+<LI><A HREF="#ftype_integer">TYPE_INTEGER</A>
+<LI><A HREF="#ftype_numeric">TYPE_NUMERIC</A>
+<LI><A HREF="#ftype_regexp">TYPE_REGEXP</A>
+</UL>
+<LI><A HREF="#fbuffer">Direct Field Buffer Manipulation</A>
+<LI><A HREF="#formattrs">Attributes of Forms</A>
+<LI><A HREF="#fdisplay">Control of Form Display</A>
+<LI><A HREF="#fdriver">Input Processing in the Forms Driver</A>
+<UL>
+<LI><A HREF="#fpage">Page Navigation Requests</A>
+<LI><A HREF="#ffield">Inter-Field Navigation Requests</A>
+<LI><A HREF="#fifield">Intra-Field Navigation Requests</A>
+<LI><A HREF="#fscroll">Scrolling Requests</A>
+<LI><A HREF="#fedit">Field Editing Requests</A>
+<LI><A HREF="#forder">Order Requests</A>
+<LI><A HREF="#fappcmds">Application Commands</A>
+</UL>
+<LI><A HREF="#fhooks">Field Change Hooks</A>
+<LI><A HREF="#ffocus">Field Change Commands</A>
+<LI><A HREF="#frmoptions">Form Options</A>
+<LI><A HREF="#fcustom">Custom Validation Types</A>
+<UL>
+<LI><A HREF="#flinktypes">Union Types</A>
+<LI><A HREF="#fnewtypes">New Field Types</A>
+<LI><A HREF="#fcheckargs">Validation Function Arguments</A>
+<LI><A HREF="#fcustorder">Order Functions For Custom Types</A>
+<LI><A HREF="#fcustprobs">Avoiding Problems</A>
+</UL>
+</UL>
+</UL>
+
+<HR>
+<H1><A NAME="introduction">Introduction</A></H1>
+
+This document is an introduction to programming with <CODE>curses</CODE>. It is
+not an exhaustive reference for the curses Application Programming Interface
+(API); that role is filled by the <CODE>curses</CODE> manual pages. Rather, it
+is intended to help C programmers ease into using the package. <P>
+
+This document is aimed at C applications programmers not yet specifically
+familiar with ncurses. If you are already an experienced <CODE>curses</CODE>
+programmer, you should nevertheless read the sections on
+<A HREF="#mouse">Mouse Interfacing</A>, <A HREF="#debugging">Debugging</A>,
+<A HREF="#compat">Compatibility with Older Versions</A>,
+and <A HREF="#hints">Hints, Tips, and Tricks</A>. These will bring you up
+to speed on the special features and quirks of the <CODE>ncurses</CODE>
+implementation. If you are not so experienced, keep reading. <P>
+
+The <CODE>curses</CODE> package is a subroutine library for
+terminal-independent screen-painting and input-event handling which
+presents a high level screen model to the programmer, hiding differences
+between terminal types and doing automatic optimization of output to change
+one screen full of text into another. <CODE>Curses</CODE> uses terminfo, which
+is a database format that can describe the capabilities of thousands of
+different terminals. <P>
+
+The <CODE>curses</CODE> API may seem something of an archaism on UNIX desktops
+increasingly dominated by X, Motif, and Tcl/Tk. Nevertheless, UNIX still
+supports tty lines and X supports <EM>xterm(1)</EM>; the <CODE>curses</CODE>
+API has the advantage of (a) back-portability to character-cell terminals,
+and (b) simplicity. For an application that does not require bit-mapped
+graphics and multiple fonts, an interface implementation using <CODE>curses</CODE>
+will typically be a great deal simpler and less expensive than one using an
+X toolkit. <P>
+
+<H2><A NAME="history">A Brief History of Curses</A></H2>
+
+Historically, the first ancestor of <CODE>curses</CODE> was the routines written to
+provide screen-handling for the game <CODE>rogue</CODE>; these used the
+already-existing <CODE>termcap</CODE> database facility for describing terminal
+capabilities. These routines were abstracted into a documented library and
+first released with the early BSD UNIX versions. <P>
+
+System III UNIX from Bell Labs featured a rewritten and much-improved
+<CODE>curses</CODE> library. It introduced the terminfo format. Terminfo is based
+on Berkeley's termcap database, but contains a number of improvements and
+extensions. Parameterized capabilities strings were introduced, making it
+possible to describe multiple video attributes, and colors and to handle far
+more unusual terminals than possible with termcap. In the later AT&amp;T
+System V releases, <CODE>curses</CODE> evolved to use more facilities and offer
+more capabilities, going far beyond BSD curses in power and flexibility.<P>
+
+<H2><A NAME="scope">Scope of This Document</A></H2>
+
+This document describes <CODE>ncurses</CODE>, a free implementation of
+the System V <CODE>curses</CODE> API with some clearly marked extensions.
+It includes the following System V curses features: <P>
+<UL>
+<LI>Support for multiple screen highlights (BSD curses could only
+handle one `standout' highlight, usually reverse-video). <P>
+<LI>Support for line- and box-drawing using forms characters. <P>
+<LI>Recognition of function keys on input. <P>
+<LI>Color support. <P>
+<LI>Support for pads (windows of larger than screen size on which the
+screen or a subwindow defines a viewport).
+</UL>
+
+Also, this package makes use of the insert and delete line and character
+features of terminals so equipped, and determines how to optimally use these
+features with no help from the programmer. It allows arbitrary combinations of
+video attributes to be displayed, even on terminals that leave ``magic
+cookies'' on the screen to mark changes in attributes. <P>
+
+The <CODE>ncurses</CODE> package can also capture and use event reports from a
+mouse in some environments (notably, xterm under the X window system). This
+document includes tips for using the mouse. <P>
+
+The <CODE>ncurses</CODE> package was originated by Pavel Curtis. The original
+maintainer of this package is
+<A HREF="mailto:zmbenhal@netcom.com">Zeyd Ben-Halim</A>
+&lt;zmbenhal@netcom.com&gt;.
+<A HREF="mailto:esr@snark.thyrsus.com">Eric S. Raymond</A>
+&lt;esr@snark.thyrsus.com&gt;
+wrote many of the new features in versions after 1.8.1
+and wrote most of this introduction.
+<A HREF="mailto:juergen.pfeifer@gmx.net">J&uuml;rgen Pfeifer</A>
+wrote all of the menu and forms code as well as the
+<A HREF="http://www.adahome.com">Ada95</A> binding.
+Ongoing work is being done by
+<A HREF="mailto:dickey@clark.net">Thomas Dickey</A>
+and
+<A HREF="mailto:juergen.pfeifer@gmx.net">J&uuml;rgen Pfeifer</A>.
+<A HREF="mailto:florian@gnu.org">Florian La Roche</A>
+acts as the maintainer for the Free Software Foundation, which holds the
+copyright on ncurses.
+Contact the current maintainers at
+<A HREF="mailto:bug-ncurses@gnu.org">bug-ncurses@gnu.org</A>.
+<P>
+
+This document also describes the <A HREF="#panels">panels</A> extension library,
+similarly modeled on the SVr4 panels facility. This library allows you to
+associate backing store with each of a stack or deck of overlapping windows,
+and provides operations for moving windows around in the stack that change
+their visibility in the natural way (handling window overlaps). <P>
+
+Finally, this document describes in detail the <A HREF="#menu">menus</A> and <A
+HREF="#form">forms</A> extension libraries, also cloned from System V,
+which support easy construction and sequences of menus and fill-in
+forms. <P>
+
+
+<H2><A NAME="terminology">Terminology</A></H2>
+
+In this document, the following terminology is used with reasonable
+consistency:
+
+<DL>
+<DT> window
+<DD>
+A data structure describing a sub-rectangle of the screen (possibly the
+entire screen). You can write to a window as though it were a miniature
+screen, scrolling independently of other windows on the physical screen. <P>
+<DT> screens
+<DD>
+A subset of windows which are as large as the terminal screen, i.e., they start
+at the upper left hand corner and encompass the lower right hand corner. One
+of these, <CODE>stdscr</CODE>, is automatically provided for the programmer. <P>
+<DT> terminal screen
+<DD>
+The package's idea of what the terminal display currently looks like, i.e.,
+what the user sees now. This is a special screen.
+</DL>
+
+<H1><A NAME="curses">The Curses Library</A></H1>
+
+<H2><A NAME="overview">An Overview of Curses</A></H2>
+
+<H3><A NAME="compiling">Compiling Programs using Curses</A></H3>
+
+In order to use the library, it is necessary to have certain types and
+variables defined. Therefore, the programmer must have a line:
+
+<PRE>
+ #include &lt;curses.h&gt;
+</PRE>
+
+at the top of the program source. The screen package uses the Standard I/O
+library, so <CODE>&lt;curses.h&gt;</CODE> includes
+<CODE>&lt;stdio.h&gt;</CODE>. <CODE>&lt;curses.h&gt;</CODE> also includes
+<CODE>&lt;termios.h&gt;</CODE>, <CODE>&lt;termio.h&gt;</CODE>, or
+<CODE>&lt;sgtty.h&gt;</CODE> depending on your system. It is redundant (but
+harmless) for the programmer to do these includes, too. In linking with
+<CODE>curses</CODE> you need to have <CODE>-lncurses</CODE> in your LDFLAGS or on the
+command line. There is no need for any other libraries.
+
+<H3><A NAME="updating">Updating the Screen</A></H3>
+
+In order to update the screen optimally, it is necessary for the routines to
+know what the screen currently looks like and what the programmer wants it to
+look like next. For this purpose, a data type (structure) named WINDOW is
+defined which describes a window image to the routines, including its starting
+position on the screen (the (y, x) coordinates of the upper left hand corner)
+and its size. One of these (called <CODE>curscr</CODE>, for current screen) is a
+screen image of what the terminal currently looks like. Another screen (called
+<CODE>stdscr</CODE>, for standard screen) is provided by default to make changes
+on. <P>
+
+A window is a purely internal representation. It is used to build and store a
+potential image of a portion of the terminal. It doesn't bear any necessary
+relation to what is really on the terminal screen; it's more like a
+scratchpad or write buffer. <P>
+
+To make the section of physical screen corresponding to a window reflect the
+contents of the window structure, the routine <CODE>refresh()</CODE> (or
+<CODE>wrefresh()</CODE> if the window is not <CODE>stdscr</CODE>) is called. <P>
+
+A given physical screen section may be within the scope of any number of
+overlapping windows. Also, changes can be made to windows in any order,
+without regard to motion efficiency. Then, at will, the programmer can
+effectively say ``make it look like this,'' and let the package implementation
+determine the most efficient way to repaint the screen. <P>
+
+<H3><A NAME="stdscr">Standard Windows and Function Naming Conventions</A></H3>
+
+As hinted above, the routines can use several windows, but two are
+automatically given: <CODE>curscr</CODE>, which knows what the terminal looks like,
+and <CODE>stdscr</CODE>, which is what the programmer wants the terminal to look
+like next. The user should never actually access <CODE>curscr</CODE> directly.
+Changes should be made to through the API, and then the routine
+<CODE>refresh()</CODE> (or <CODE>wrefresh()</CODE>) called. <P>
+
+Many functions are defined to use <CODE>stdscr</CODE> as a default screen. For
+example, to add a character to <CODE>stdscr</CODE>, one calls <CODE>addch()</CODE> with
+the desired character as argument. To write to a different window. use the
+routine <CODE>waddch()</CODE> (for `w'indow-specific addch()) is provided. This
+convention of prepending function names with a `w' when they are to be
+applied to specific windows is consistent. The only routines which do not
+follow it are those for which a window must always be specified. <P>
+
+In order to move the current (y, x) coordinates from one point to another, the
+routines <CODE>move()</CODE> and <CODE>wmove()</CODE> are provided. However, it is
+often desirable to first move and then perform some I/O operation. In order to
+avoid clumsiness, most I/O routines can be preceded by the prefix 'mv' and
+the desired (y, x) coordinates prepended to the arguments to the function. For
+example, the calls
+
+<PRE>
+ move(y, x);
+ addch(ch);
+</PRE>
+
+can be replaced by
+
+<PRE>
+ mvaddch(y, x, ch);
+</PRE>
+
+and
+
+<PRE>
+ wmove(win, y, x);
+ waddch(win, ch);
+</PRE>
+
+can be replaced by
+
+<PRE>
+ mvwaddch(win, y, x, ch);
+</PRE>
+
+Note that the window description pointer (win) comes before the added (y, x)
+coordinates. If a function requires a window pointer, it is always the first
+parameter passed. <P>
+
+<H3><A NAME="variables">Variables</A></H3>
+
+The <CODE>curses</CODE> library sets some variables describing the terminal
+capabilities.
+
+<PRE>
+ type name description
+ ------------------------------------------------------------------
+ int LINES number of lines on the terminal
+ int COLS number of columns on the terminal
+</PRE>
+
+The <CODE>curses.h</CODE> also introduces some <CODE>#define</CODE> constants and types
+of general usefulness:
+
+<DL>
+<DT> <CODE>bool</CODE>
+<DD> boolean type, actually a `char' (e.g., <CODE>bool doneit;</CODE>)
+<DT> <CODE>TRUE</CODE>
+<DD> boolean `true' flag (1).
+<DT> <CODE>FALSE</CODE>
+<DD> boolean `false' flag (0).
+<DT> <CODE>ERR</CODE>
+<DD> error flag returned by routines on a failure (-1).
+<DT> <CODE>OK</CODE>
+<DD> error flag returned by routines when things go right.
+</DL>
+
+<H2><A NAME="using">Using the Library</A></H2>
+
+Now we describe how to actually use the screen package. In it, we assume all
+updating, reading, etc. is applied to <CODE>stdscr</CODE>. These instructions will
+work on any window, providing you change the function names and parameters as
+mentioned above. <P>
+
+Here is a sample program to motivate the discussion: <P>
+
+<PRE>
+#include &lt;curses.h&gt;
+#include &lt;signal.h&gt;
+
+static void finish(int sig);
+
+main(int argc, char *argv[])
+{
+ /* initialize your non-curses data structures here */
+
+ (void) signal(SIGINT, finish); /* arrange interrupts to terminate */
+
+ (void) initscr(); /* initialize the curses library */
+ keypad(stdscr, TRUE); /* enable keyboard mapping */
+ (void) nonl(); /* tell curses not to do NL-&gt;CR/NL on output */
+ (void) cbreak(); /* take input chars one at a time, no wait for \n */
+ (void) noecho(); /* don't echo input */
+
+ if (has_colors())
+ {
+ start_color();
+
+ /*
+ * Simple color assignment, often all we need.
+ */
+ init_pair(COLOR_BLACK, COLOR_BLACK, COLOR_BLACK);
+ init_pair(COLOR_GREEN, COLOR_GREEN, COLOR_BLACK);
+ init_pair(COLOR_RED, COLOR_RED, COLOR_BLACK);
+ init_pair(COLOR_CYAN, COLOR_CYAN, COLOR_BLACK);
+ init_pair(COLOR_WHITE, COLOR_WHITE, COLOR_BLACK);
+ init_pair(COLOR_MAGENTA, COLOR_MAGENTA, COLOR_BLACK);
+ init_pair(COLOR_BLUE, COLOR_BLUE, COLOR_BLACK);
+ init_pair(COLOR_YELLOW, COLOR_YELLOW, COLOR_BLACK);
+ }
+
+ for (;;)
+ {
+ int c = getch(); /* refresh, accept single keystroke of input */
+
+ /* process the command keystroke */
+ }
+
+ finish(0); /* we're done */
+}
+
+static void finish(int sig)
+{
+ endwin();
+
+ /* do your non-curses wrapup here */
+
+ exit(0);
+}
+</PRE>
+
+<H3><A NAME="starting">Starting up</A></H3>
+
+In order to use the screen package, the routines must know about terminal
+characteristics, and the space for <CODE>curscr</CODE> and <CODE>stdscr</CODE> must be
+allocated. These function <CODE>initscr()</CODE> does both these things. Since it
+must allocate space for the windows, it can overflow memory when attempting to
+do so. On the rare occasions this happens, <CODE>initscr()</CODE> will terminate
+the program with an error message. <CODE>initscr()</CODE> must always be called
+before any of the routines which affect windows are used. If it is not, the
+program will core dump as soon as either <CODE>curscr</CODE> or <CODE>stdscr</CODE> are
+referenced. However, it is usually best to wait to call it until after you are
+sure you will need it, like after checking for startup errors. Terminal status
+changing routines like <CODE>nl()</CODE> and <CODE>cbreak()</CODE> should be called
+after <CODE>initscr()</CODE>. <P>
+
+Once the screen windows have been allocated, you can set them up for
+your program. If you want to, say, allow a screen to scroll, use
+<CODE>scrollok()</CODE>. If you want the cursor to be left in place after
+the last change, use <CODE>leaveok()</CODE>. If this isn't done,
+<CODE>refresh()</CODE> will move the cursor to the window's current (y, x)
+coordinates after updating it. <P>
+
+You can create new windows of your own using the functions <CODE>newwin()</CODE>,
+<CODE>derwin()</CODE>, and <CODE>subwin()</CODE>. The routine <CODE>delwin()</CODE> will
+allow you to get rid of old windows. All the options described above can be
+applied to any window. <P>
+
+<H3><A NAME="output">Output</A></H3>
+
+Now that we have set things up, we will want to actually update the terminal.
+The basic functions used to change what will go on a window are
+<CODE>addch()</CODE> and <CODE>move()</CODE>. <CODE>addch()</CODE> adds a character at the
+current (y, x) coordinates. <CODE>move()</CODE> changes the current (y, x)
+coordinates to whatever you want them to be. It returns <CODE>ERR</CODE> if you
+try to move off the window. As mentioned above, you can combine the two into
+<CODE>mvaddch()</CODE> to do both things at once. <P>
+
+The other output functions, such as <CODE>addstr()</CODE> and <CODE>printw()</CODE>,
+all call <CODE>addch()</CODE> to add characters to the window. <P>
+
+After you have put on the window what you want there, when you want the portion
+of the terminal covered by the window to be made to look like it, you must call
+<CODE>refresh()</CODE>. In order to optimize finding changes, <CODE>refresh()</CODE>
+assumes that any part of the window not changed since the last
+<CODE>refresh()</CODE> of that window has not been changed on the terminal, i.e.,
+that you have not refreshed a portion of the terminal with an overlapping
+window. If this is not the case, the routine <CODE>touchwin()</CODE> is provided
+to make it look like the entire window has been changed, thus making
+<CODE>refresh()</CODE> check the whole subsection of the terminal for changes. <P>
+
+If you call <CODE>wrefresh()</CODE> with <CODE>curscr</CODE> as its argument, it will
+make the screen look like <CODE>curscr</CODE> thinks it looks like. This is useful
+for implementing a command which would redraw the screen in case it get messed
+up. <P>
+
+<H3><A NAME="input">Input</A></H3>
+
+The complementary function to <CODE>addch()</CODE> is <CODE>getch()</CODE> which, if
+echo is set, will call <CODE>addch()</CODE> to echo the character. Since the
+screen package needs to know what is on the terminal at all times, if
+characters are to be echoed, the tty must be in raw or cbreak mode. Since
+initially the terminal has echoing enabled and is in ordinary ``cooked'' mode,
+one or the other has to changed before calling <CODE>getch()</CODE>; otherwise,
+the program's output will be unpredictable. <P>
+
+When you need to accept line-oriented input in a window, the functions
+<CODE>wgetstr()</CODE> and friends are available. There is even a <CODE>wscanw()</CODE>
+function that can do <CODE>scanf()</CODE>(3)-style multi-field parsing on window
+input. These pseudo-line-oriented functions turn on echoing while they
+execute. <P>
+
+The example code above uses the call <CODE>keypad(stdscr, TRUE)</CODE> to enable
+support for function-key mapping. With this feature, the <CODE>getch()</CODE> code
+watches the input stream for character sequences that correspond to arrow and
+function keys. These sequences are returned as pseudo-character values. The
+<CODE>#define</CODE> values returned are listed in the <CODE>curses.h</CODE> The
+mapping from sequences to <CODE>#define</CODE> values is determined by
+<CODE>key_</CODE> capabilities in the terminal's terminfo entry. <P>
+
+<H3><A NAME="formschars">Using Forms Characters</A></H3>
+
+The <CODE>addch()</CODE> function (and some others, including <CODE>box()</CODE> and
+<CODE>border()</CODE>) can accept some pseudo-character arguments which are specially
+defined by <CODE>ncurses</CODE>. These are <CODE>#define</CODE> values set up in
+the <CODE>curses.h</CODE> header; see there for a complete list (look for
+the prefix <CODE>ACS_</CODE>). <P>
+
+The most useful of the ACS defines are the forms-drawing characters. You can
+use these to draw boxes and simple graphs on the screen. If the terminal
+does not have such characters, <CODE>curses.h</CODE> will map them to a
+recognizable (though ugly) set of ASCII defaults. <P>
+
+<H3><A NAME="attributes">Character Attributes and Color</A></H3>
+
+The <CODE>ncurses</CODE> package supports screen highlights including standout,
+reverse-video, underline, and blink. It also supports color, which is treated
+as another kind of highlight. <P>
+
+Highlights are encoded, internally, as high bits of the pseudo-character type
+(<CODE>chtype</CODE>) that <CODE>curses.h</CODE> uses to represent the contents of a
+screen cell. See the <CODE>curses.h</CODE> header file for a complete list of
+highlight mask values (look for the prefix <CODE>A_</CODE>).<P>
+
+There are two ways to make highlights. One is to logical-or the value of the
+highlights you want into the character argument of an <CODE>addch()</CODE> call,
+or any other output call that takes a <CODE>chtype</CODE> argument. <P>
+
+The other is to set the current-highlight value. This is logical-or'ed with
+any highlight you specify the first way. You do this with the functions
+<CODE>attron()</CODE>, <CODE>attroff()</CODE>, and <CODE>attrset()</CODE>; see the manual
+pages for details.
+
+Color is a special kind of highlight. The package actually thinks in terms
+of color pairs, combinations of foreground and background colors. The sample
+code above sets up eight color pairs, all of the guaranteed-available colors
+on black. Note that each color pair is, in effect, given the name of its
+foreground color. Any other range of eight non-conflicting values could
+have been used as the first arguments of the <CODE>init_pair()</CODE> values. <P>
+
+Once you've done an <CODE>init_pair()</CODE> that creates color-pair N, you can
+use <CODE>COLOR_PAIR(N)</CODE> as a highlight that invokes that particular
+color combination. Note that <CODE>COLOR_PAIR(N)</CODE>, for constant N,
+is itself a compile-time constant and can be used in initializers. <P>
+
+<H3><A NAME="mouse">Mouse Interfacing</A></H3>
+
+The <CODE>ncurses</CODE> library also provides a mouse interface.
+<!-- The 'note' tag is not portable enough -->
+<blockquote>
+<strong>NOTE:</strong> this facility is specific to <CODE>ncurses</CODE>, it is not part of either
+the XSI Curses standard, nor of System V Release 4, nor BSD curses.
+System V Release 4 curses contains code with similar interface definitions,
+however it is not documented. Other than by disassembling the library, we
+have no way to determine exactly how that mouse code works.
+Thus, we recommend that you wrap mouse-related code in an #ifdef using the
+feature macro NCURSES_MOUSE_VERSION so it will not be compiled and linked
+on non-ncurses systems.
+</blockquote>
+
+Presently, mouse event reporting works in the following environments:
+<ul>
+<li>xterm and similar programs such as rxvt.
+<li>Linux console, when configured with <CODE>gpm</CODE>(1), Alessandro
+Rubini's mouse server.
+<li>OS/2 EMX
+</ul>
+<P>
+The mouse interface is very simple. To activate it, you use the function
+<CODE>mousemask()</CODE>, passing it as first argument a bit-mask that specifies
+what kinds of events you want your program to be able to see. It will
+return the bit-mask of events that actually become visible, which may differ
+from the argument if the mouse device is not capable of reporting some of
+the event types you specify. <P>
+
+Once the mouse is active, your application's command loop should watch
+for a return value of <CODE>KEY_MOUSE</CODE> from <CODE>wgetch()</CODE>. When
+you see this, a mouse event report has been queued. To pick it off
+the queue, use the function <CODE>getmouse()</CODE> (you must do this before
+the next <CODE>wgetch()</CODE>, otherwise another mouse event might come
+in and make the first one inaccessible). <P>
+
+Each call to <CODE>getmouse()</CODE> fills a structure (the address of which you'll
+pass it) with mouse event data. The event data includes zero-origin,
+screen-relative character-cell coordinates of the mouse pointer. It also
+includes an event mask. Bits in this mask will be set, corresponding
+to the event type being reported. <P>
+
+The mouse structure contains two additional fields which may be
+significant in the future as ncurses interfaces to new kinds of
+pointing device. In addition to x and y coordinates, there is a slot
+for a z coordinate; this might be useful with touch-screens that can
+return a pressure or duration parameter. There is also a device ID
+field, which could be used to distinguish between multiple pointing
+devices. <P>
+
+The class of visible events may be changed at any time via <CODE>mousemask()</CODE>.
+Events that can be reported include presses, releases, single-, double- and
+triple-clicks (you can set the maximum button-down time for clicks). If
+you don't make clicks visible, they will be reported as press-release
+pairs. In some environments, the event mask may include bits reporting
+the state of shift, alt, and ctrl keys on the keyboard during the event. <P>
+
+A function to check whether a mouse event fell within a given window is
+also supplied. You can use this to see whether a given window should
+consider a mouse event relevant to it. <P>
+
+Because mouse event reporting will not be available in all
+environments, it would be unwise to build <CODE>ncurses</CODE>
+applications that <EM>require</EM> the use of a mouse. Rather, you should
+use the mouse as a shortcut for point-and-shoot commands your application
+would normally accept from the keyboard. Two of the test games in the
+<CODE>ncurses</CODE> distribution (<CODE>bs</CODE> and <CODE>knight</CODE>) contain
+code that illustrates how this can be done. <P>
+
+See the manual page <CODE>curs_mouse(3X)</CODE> for full details of the
+mouse-interface functions. <P>
+
+<H3><A NAME="finishing">Finishing Up</A></H3>
+
+In order to clean up after the <CODE>ncurses</CODE> routines, the routine
+<CODE>endwin()</CODE> is provided. It restores tty modes to what they were when
+<CODE>initscr()</CODE> was first called, and moves the cursor down to the
+lower-left corner. Thus, anytime after the call to initscr, <CODE>endwin()</CODE>
+should be called before exiting. <P>
+
+<H2><A NAME="functions">Function Descriptions</A></H2>
+
+We describe the detailed behavior of some important curses functions here, as a
+supplement to the manual page descriptions.
+
+<H3><A NAME="init">Initialization and Wrapup</A></H3>
+
+<DL>
+<DT> <CODE>initscr()</CODE>
+<DD> The first function called should almost always be <CODE>initscr()</CODE>.
+This will determine the terminal type and
+initialize curses data structures. <CODE>initscr()</CODE> also arranges that
+the first call to <CODE>refresh()</CODE> will clear the screen. If an error
+occurs a message is written to standard error and the program
+exits. Otherwise it returns a pointer to stdscr. A few functions may be
+called before initscr (<CODE>slk_init()</CODE>, <CODE>filter()</CODE>,
+<CODE>ripofflines()</CODE>, <CODE>use_env()</CODE>, and, if you are using multiple
+terminals, <CODE>newterm()</CODE>.) <P>
+<DT> <CODE>endwin()</CODE>
+<DD> Your program should always call <CODE>endwin()</CODE> before exiting or
+shelling out of the program. This function will restore tty modes,
+move the cursor to the lower left corner of the screen, reset the
+terminal into the proper non-visual mode. Calling <CODE>refresh()</CODE>
+or <CODE>doupdate()</CODE> after a temporary escape from the program will
+restore the ncurses screen from before the escape. <P>
+<DT> <CODE>newterm(type, ofp, ifp)</CODE>
+<DD> A program which outputs to more than one terminal should use
+<CODE>newterm()</CODE> instead of <CODE>initscr()</CODE>. <CODE>newterm()</CODE> should
+be called once for each terminal. It returns a variable of type
+<CODE>SCREEN *</CODE> which should be saved as a reference to that
+terminal. The arguments are the type of the terminal (a string) and
+<CODE>FILE</CODE> pointers for the output and input of the terminal. If
+type is NULL then the environment variable <CODE>$TERM</CODE> is used.
+<CODE>endwin()</CODE> should called once at wrapup time for each terminal
+opened using this function. <P>
+<DT> <CODE>set_term(new)</CODE>
+<DD> This function is used to switch to a different terminal previously
+opened by <CODE>newterm()</CODE>. The screen reference for the new terminal
+is passed as the parameter. The previous terminal is returned by the
+function. All other calls affect only the current terminal. <P>
+<DT> <CODE>delscreen(sp)</CODE>
+<DD> The inverse of <CODE>newterm()</CODE>; deallocates the data structures
+associated with a given <CODE>SCREEN</CODE> reference.
+</DL>
+
+<H3><A NAME="flush">Causing Output to the Terminal</A></H3>
+
+<DL>
+<DT> <CODE>refresh()</CODE> and <CODE>wrefresh(win)</CODE>
+<DD> These functions must be called to actually get any output on
+the terminal, as other routines merely manipulate data
+structures. <CODE>wrefresh()</CODE> copies the named window to the physical
+terminal screen, taking into account what is already
+there in order to do optimizations. <CODE>refresh()</CODE> does a
+refresh of <CODE>stdscr()</CODE>. Unless <CODE>leaveok()</CODE> has been
+enabled, the physical cursor of the terminal is left at the
+location of the window's cursor. <P>
+<DT> <CODE>doupdate()</CODE> and <CODE>wnoutrefresh(win)</CODE>
+<DD> These two functions allow multiple updates with more efficiency
+than wrefresh. To use them, it is important to understand how curses
+works. In addition to all the window structures, curses keeps two
+data structures representing the terminal screen: a physical screen,
+describing what is actually on the screen, and a virtual screen,
+describing what the programmer wants to have on the screen. wrefresh
+works by first copying the named window to the virtual screen
+(<CODE>wnoutrefresh()</CODE>), and then calling the routine to update the
+screen (<CODE>doupdate()</CODE>). If the programmer wishes to output
+several windows at once, a series of calls to <CODE>wrefresh</CODE> will result
+in alternating calls to <CODE>wnoutrefresh()</CODE> and <CODE>doupdate()</CODE>,
+causing several bursts of output to the screen. By calling
+<CODE>wnoutrefresh()</CODE> for each window, it is then possible to call
+<CODE>doupdate()</CODE> once, resulting in only one burst of output, with
+fewer total characters transmitted (this also avoids a visually annoying
+flicker at each update).
+</DL>
+
+<H3><A NAME="lowlevel">Low-Level Capability Access</A></H3>
+
+<DL>
+<DT> <CODE>setupterm(term, filenum, errret)</CODE>
+<DD> This routine is called to initialize a terminal's description, without setting
+up the curses screen structures or changing the tty-driver mode bits.
+<CODE>term</CODE> is the character string representing the name of the terminal
+being used. <CODE>filenum</CODE> is the UNIX file descriptor of the terminal to
+be used for output. <CODE>errret</CODE> is a pointer to an integer, in which a
+success or failure indication is returned. The values returned can be 1 (all
+is well), 0 (no such terminal), or -1 (some problem locating the terminfo
+database). <P>
+
+The value of <CODE>term</CODE> can be given as NULL, which will cause the value of
+<CODE>TERM</CODE> in the environment to be used. The <CODE>errret</CODE> pointer can
+also be given as NULL, meaning no error code is wanted. If <CODE>errret</CODE> is
+defaulted, and something goes wrong, <CODE>setupterm()</CODE> will print an
+appropriate error message and exit, rather than returning. Thus, a simple
+program can call setupterm(0, 1, 0) and not worry about initialization
+errors. <P>
+
+After the call to <CODE>setupterm()</CODE>, the global variable <CODE>cur_term</CODE> is
+set to point to the current structure of terminal capabilities. By calling
+<CODE>setupterm()</CODE> for each terminal, and saving and restoring
+<CODE>cur_term</CODE>, it is possible for a program to use two or more terminals at
+once. <CODE>Setupterm()</CODE> also stores the names section of the terminal
+description in the global character array <CODE>ttytype[]</CODE>. Subsequent calls
+to <CODE>setupterm()</CODE> will overwrite this array, so you'll have to save it
+yourself if need be.
+</DL>
+
+<H3><A NAME="debugging">Debugging</A></H3>
+
+<!-- The 'note' tag is not portable enough -->
+<blockquote>
+<strong>NOTE:</strong> These functions are not part of the standard curses API!
+</blockquote>
+
+<DL>
+<DT> <CODE>trace()</CODE>
+<DD>
+This function can be used to explicitly set a trace level. If the
+trace level is nonzero, execution of your program will generate a file
+called `trace' in the current working directory containing a report on
+the library's actions. Higher trace levels enable more detailed (and
+verbose) reporting -- see comments attached to <CODE>TRACE_</CODE> defines
+in the <CODE>curses.h</CODE> file for details. (It is also possible to set
+a trace level by assigning a trace level value to the environment variable
+<CODE>NCURSES_TRACE</CODE>).
+<DT> <CODE>_tracef()</CODE>
+<DD>
+This function can be used to output your own debugging information. It is only
+available only if you link with -lncurses_g. It can be used the same way as
+<CODE>printf()</CODE>, only it outputs a newline after the end of arguments.
+The output goes to a file called <CODE>trace</CODE> in the current directory.
+</DL>
+
+Trace logs can be difficult to interpret due to the sheer volume of
+data dumped in them. There is a script called <STRONG>tracemunch</STRONG>
+included with the <CODE>ncurses</CODE> distribution that can alleviate
+this problem somewhat; it compacts long sequences of similar operations into
+more succinct single-line pseudo-operations. These pseudo-ops can be
+distinguished by the fact that they are named in capital letters.<P>
+
+<H2><A NAME="hints">Hints, Tips, and Tricks</A></H2>
+
+The <CODE>ncurses</CODE> manual pages are a complete reference for this library.
+In the remainder of this document, we discuss various useful methods that
+may not be obvious from the manual page descriptions. <P>
+
+<H3><A NAME="caution">Some Notes of Caution</A></H3>
+
+If you find yourself thinking you need to use <CODE>noraw()</CODE> or
+<CODE>nocbreak()</CODE>, think again and move carefully. It's probably
+better design to use <CODE>getstr()</CODE> or one of its relatives to
+simulate cooked mode. The <CODE>noraw()</CODE> and <CODE>nocbreak()</CODE>
+functions try to restore cooked mode, but they may end up clobbering
+some control bits set before you started your application. Also, they
+have always been poorly documented, and are likely to hurt your
+application's usability with other curses libraries. <P>
+
+Bear in mind that <CODE>refresh()</CODE> is a synonym for <CODE>wrefresh(stdscr)</CODE>.
+Don't try to mix use of <CODE>stdscr</CODE> with use of windows declared
+by <CODE>newwin()</CODE>; a <CODE>refresh()</CODE> call will blow them off the
+screen. The right way to handle this is to use <CODE>subwin()</CODE>, or
+not touch <CODE>stdscr</CODE> at all and tile your screen with declared
+windows which you then <CODE>wnoutrefresh()</CODE> somewhere in your program
+event loop, with a single <CODE>doupdate()</CODE> call to trigger actual
+repainting. <P>
+
+You are much less likely to run into problems if you design your screen
+layouts to use tiled rather than overlapping windows. Historically,
+curses support for overlapping windows has been weak, fragile, and poorly
+documented. The <CODE>ncurses</CODE> library is not yet an exception to this
+rule. <P>
+
+There is a panels library included in the <CODE>ncurses</CODE>
+distribution that does a pretty good job of strengthening the
+overlapping-windows facilities. <P>
+
+Try to avoid using the global variables LINES and COLS. Use
+<CODE>getmaxyx()</CODE> on the <CODE>stdscr</CODE> context instead. Reason:
+your code may be ported to run in an environment with window resizes,
+in which case several screens could be open with different sizes. <P>
+
+<H3><A NAME="leaving">Temporarily Leaving NCURSES Mode</A></H3>
+
+Sometimes you will want to write a program that spends most of its time in
+screen mode, but occasionally returns to ordinary `cooked' mode. A common
+reason for this is to support shell-out. This behavior is simple to arrange
+in <CODE>ncurses</CODE>. <P>
+
+To leave <CODE>ncurses</CODE> mode, call <CODE>endwin()</CODE> as you would if you
+were intending to terminate the program. This will take the screen back to
+cooked mode; you can do your shell-out. When you want to return to
+<CODE>ncurses</CODE> mode, simply call <CODE>refresh()</CODE> or <CODE>doupdate()</CODE>.
+This will repaint the screen. <P>
+
+There is a boolean function, <CODE>isendwin()</CODE>, which code can use to
+test whether <CODE>ncurses</CODE> screen mode is active. It returns <CODE>TRUE</CODE>
+in the interval between an <CODE>endwin()</CODE> call and the following
+<CODE>refresh()</CODE>, <CODE>FALSE</CODE> otherwise. <P>
+
+Here is some sample code for shellout:
+
+<PRE>
+ addstr("Shelling out...");
+ def_prog_mode(); /* save current tty modes */
+ endwin(); /* restore original tty modes */
+ system("sh"); /* run shell */
+ addstr("returned.\n"); /* prepare return message */
+ refresh(); /* restore save modes, repaint screen */
+</PRE>
+
+<H3><A NAME="xterm">Using NCURSES under XTERM</A></H3>
+
+A resize operation in X sends SIGWINCH to the application running under xterm.
+The <CODE>ncurses</CODE> library provides an experimental signal
+handler, but in general does not catch this signal, because it cannot
+know how you want the screen re-painted. You will usually have to write the
+SIGWINCH handler yourself. Ncurses can give you some help. <P>
+
+The easiest way to code your SIGWINCH handler is to have it do an
+<CODE>endwin</CODE>, followed by an <CODE>refresh</CODE> and a screen repaint you code
+yourself. The <CODE>refresh</CODE> will pick up the new screen size from the
+xterm's environment. <P>
+
+That is the standard way, of course (it even works with some vendor's curses
+implementations).
+Its drawback is that it clears the screen to reinitialize the display, and does
+not resize subwindows which must be shrunk.
+<CODE>Ncurses</CODE> provides an extension which works better, the
+<CODE>resizeterm</CODE> function. That function ensures that all windows
+are limited to the new screen dimensions, and pads <CODE>stdscr</CODE>
+with blanks if the screen is larger. <P>
+
+Finally, ncurses can be configured to provide its own SIGWINCH handler,
+based on <CODE>resizeterm</CODE>.
+
+<H3><A NAME="screens">Handling Multiple Terminal Screens</A></H3>
+
+The <CODE>initscr()</CODE> function actually calls a function named
+<CODE>newterm()</CODE> to do most of its work. If you are writing a program that
+opens multiple terminals, use <CODE>newterm()</CODE> directly. <P>
+
+For each call, you will have to specify a terminal type and a pair of file
+pointers; each call will return a screen reference, and <CODE>stdscr</CODE> will be
+set to the last one allocated. You will switch between screens with the
+<CODE>set_term</CODE> call. Note that you will also have to call
+<CODE>def_shell_mode</CODE> and <CODE>def_prog_mode</CODE> on each tty yourself. <P>
+
+<H3><A NAME="testing">Testing for Terminal Capabilities</A></H3>
+
+Sometimes you may want to write programs that test for the presence of various
+capabilities before deciding whether to go into <CODE>ncurses</CODE> mode. An easy
+way to do this is to call <CODE>setupterm()</CODE>, then use the functions
+<CODE>tigetflag()</CODE>, <CODE>tigetnum()</CODE>, and <CODE>tigetstr()</CODE> to do your
+testing. <P>
+
+A particularly useful case of this often comes up when you want to
+test whether a given terminal type should be treated as `smart'
+(cursor-addressable) or `stupid'. The right way to test this is to see
+if the return value of <CODE>tigetstr("cup")</CODE> is non-NULL. Alternatively,
+you can include the <CODE>term.h</CODE> file and test the value of the
+macro <CODE>cursor_address</CODE>. <P>
+
+<H3><A NAME="tuning">Tuning for Speed</A></H3>
+
+Use the <CODE>addchstr()</CODE> family of functions for fast
+screen-painting of text when you know the text doesn't contain any
+control characters. Try to make attribute changes infrequent on your
+screens. Don't use the <CODE>immedok()</CODE> option! <P>
+
+<H3><A NAME="special">Special Features of NCURSES</A></H3>
+
+The <CODE>wresize()</CODE> function allows you to resize a window in place.
+The associated <CODE>resizeterm()</CODE> function simplifies the construction
+of <a HREF="#xterm">SIGWINCH</a> handlers, for resizing all windows. <P>
+
+The <CODE>define_key()</CODE> function allows you
+to define at runtime function-key control sequences which are not in the
+terminal description.
+The <CODE>keyok()</CODE> function allows you to temporarily
+enable or disable interpretation of any function-key control sequence. <P>
+
+The <CODE>use_default_colors()</CODE> function allows you to construct
+applications which can use the terminal's default foreground and
+background colors as an additional "default" color.
+Several terminal emulators support this feature, which is based on ISO 6429. <P>
+
+Ncurses supports up 16 colors, unlike SVr4 curses which defines only 8.
+While most terminals which provide color allow only 8 colors, about
+a quarter (including XFree86 xterm) support 16 colors.
+
+<H2><A NAME="compat">Compatibility with Older Versions</A></H2>
+
+Despite our best efforts, there are some differences between <CODE>ncurses</CODE>
+and the (undocumented!) behavior of older curses implementations. These arise
+from ambiguities or omissions in the documentation of the API.
+
+<H3><A NAME="refbug">Refresh of Overlapping Windows</A></H3>
+
+If you define two windows A and B that overlap, and then alternately scribble
+on and refresh them, the changes made to the overlapping region under historic
+<CODE>curses</CODE> versions were often not documented precisely. <P>
+
+To understand why this is a problem, remember that screen updates are
+calculated between two representations of the <EM>entire</EM> display. The
+documentation says that when you refresh a window, it is first copied to to the
+virtual screen, and then changes are calculated to update the physical screen
+(and applied to the terminal). But "copied to" is not very specific, and
+subtle differences in how copying works can produce different behaviors in the
+case where two overlapping windows are each being refreshed at unpredictable
+intervals. <P>
+
+What happens to the overlapping region depends on what <CODE>wnoutrefresh()</CODE>
+does with its argument -- what portions of the argument window it copies to the
+virtual screen. Some implementations do "change copy", copying down only
+locations in the window that have changed (or been marked changed with
+<CODE>wtouchln()</CODE> and friends). Some implementations do "entire copy",
+copying <EM>all</EM> window locations to the virtual screen whether or not
+they have changed. <P>
+
+The <CODE>ncurses</CODE> library itself has not always been consistent on this
+score. Due to a bug, versions 1.8.7 to 1.9.8a did entire copy. Versions
+1.8.6 and older, and versions 1.9.9 and newer, do change copy. <P>
+
+For most commercial curses implementations, it is not documented and not known
+for sure (at least not to the <CODE>ncurses</CODE> maintainers) whether they do
+change copy or entire copy. We know that System V release 3 curses has logic
+in it that looks like an attempt to do change copy, but the surrounding logic
+and data representations are sufficiently complex, and our knowledge
+sufficiently indirect, that it's hard to know whether this is reliable.
+
+It is not clear what the SVr4 documentation and XSI standard intend. The XSI
+Curses standard barely mentions wnoutrefresh(); the SVr4 documents seem to be
+describing entire-copy, but it is possible with some effort and straining to
+read them the other way. <P>
+
+It might therefore be unwise to rely on either behavior in programs that might
+have to be linked with other curses implementations. Instead, you can do an
+explicit <CODE>touchwin()</CODE> before the <CODE>wnoutrefresh()</CODE> call to
+guarantee an entire-contents copy anywhere. <P>
+
+The really clean way to handle this is to use the panels library. If,
+when you want a screen update, you do <CODE>update_panels()</CODE>, it will
+do all the necessary <CODE>wnoutrfresh()</CODE> calls for whatever panel
+stacking order you have defined. Then you can do one <CODE>doupdate()</CODE>
+and there will be a <EM>single</EM> burst of physical I/O that will do
+all your updates. <P>
+
+<H3><A NAME="backbug">Background Erase</A></H3>
+
+If you have been using a very old versions of <CODE>ncurses</CODE> (1.8.7 or
+older) you may be surprised by the behavior of the erase functions. In older
+versions, erased areas of a window were filled with a blank modified by the
+window's current attribute (as set by <STRONG>wattrset()</STRONG>, <STRONG>wattron()</STRONG>,
+<STRONG>wattroff()</STRONG> and friends). <P>
+
+In newer versions, this is not so. Instead, the attribute of erased blanks
+is normal unless and until it is modified by the functions <CODE>bkgdset()</CODE>
+or <CODE>wbkgdset()</CODE>. <P>
+
+This change in behavior conforms <CODE>ncurses</CODE> to System V Release 4 and
+the XSI Curses standard. <P>
+
+<H2><A NAME="xsifuncs">XSI Curses Conformance</A></H2>
+
+The <CODE>ncurses</CODE> library is intended to be base-level conformant with the
+XSI Curses standard from X/Open. Many extended-level features (in fact, almost
+all features not directly concerned with wide characters and
+internationalization) are also supported. <P>
+
+One effect of XSI conformance is the change in behavior described under
+<A HREF="#backbug">"Background Erase -- Compatibility with Old Versions"</A>. <P>
+
+Also, <CODE>ncurses</CODE> meets the XSI requirement that every macro
+entry point have a corresponding function which may be linked (and
+will be prototype-checked) if the macro definition is disabled with
+<CODE>#undef</CODE>. <P>
+
+<H1><A NAME="panels">The Panels Library</A></H1>
+
+The <CODE>ncurses</CODE> library by itself provides good support for screen
+displays in which the windows are tiled (non-overlapping). In the more
+general case that windows may overlap, you have to use a series of
+<CODE>wnoutrefresh()</CODE> calls followed by a <CODE>doupdate()</CODE>, and be
+careful about the order you do the window refreshes in. It has to be
+bottom-upwards, otherwise parts of windows that should be obscured will
+show through. <P>
+
+When your interface design is such that windows may dive deeper into the
+visibility stack or pop to the top at runtime, the resulting book-keeping
+can be tedious and difficult to get right. Hence the panels library. <P>
+
+The <CODE>panel</CODE> library first appeared in AT&amp;T System V. The
+version documented here is the <CODE>panel</CODE> code distributed
+with <CODE>ncurses</CODE>.
+
+<H2><A NAME="pcompile">Compiling With the Panels Library</A></H2>
+
+Your panels-using modules must import the panels library declarations with
+
+<PRE>
+ #include &lt;panel.h&gt;
+</PRE>
+
+and must be linked explicitly with the panels library using an
+<CODE>-lpanel</CODE> argument. Note that they must also link the
+<CODE>ncurses</CODE> library with <CODE>-lncurses</CODE>. Many linkers
+are two-pass and will accept either order, but it is still good practice
+to put <CODE>-lpanel</CODE> first and <CODE>-lncurses</CODE> second.
+
+<H2><A NAME="poverview">Overview of Panels</A></H2>
+
+A panel object is a window that is implicitly treated as part of a
+<DFN>deck</DFN> including all other panel objects. The deck has an implicit
+bottom-to-top visibility order. The panels library includes an update
+function (analogous to <CODE>refresh()</CODE>) that displays all panels in the
+deck in the proper order to resolve overlaps. The standard window,
+<CODE>stdscr</CODE>, is considered below all panels. <P>
+
+Details on the panels functions are available in the man pages. We'll just
+hit the highlights here. <P>
+
+You create a panel from a window by calling <CODE>new_panel()</CODE> on a
+window pointer. It then becomes the top of the deck. The panel's window
+is available as the value of <CODE>panel_window()</CODE> called with the
+panel pointer as argument.<P>
+
+You can delete a panel (removing it from the deck) with <CODE>del_panel</CODE>.
+This will not deallocate the associated window; you have to do that yourself.
+
+You can replace a panel's window with a different window by calling
+<CODE>replace_window</CODE>. The new window may be of different size;
+the panel code will re-compute all overlaps. This operation doesn't
+change the panel's position in the deck. <P>
+
+To move a panel's window, use <CODE>move_panel()</CODE>. The
+<CODE>mvwin()</CODE> function on the panel's window isn't sufficient because it
+doesn't update the panels library's representation of where the windows are.
+This operation leaves the panel's depth, contents, and size unchanged. <P>
+
+Two functions (<CODE>top_panel()</CODE>, <CODE>bottom_panel()</CODE>) are
+provided for rearranging the deck. The first pops its argument window to the
+top of the deck; the second sends it to the bottom. Either operation leaves
+the panel's screen location, contents, and size unchanged. <P>
+
+The function <CODE>update_panels()</CODE> does all the
+<CODE>wnoutrefresh()</CODE> calls needed to prepare for
+<CODE>doupdate()</CODE> (which you must call yourself, afterwards). <P>
+
+Typically, you will want to call <CODE>update_panels()</CODE> and
+<CODE>doupdate()</CODE> just before accepting command input, once in each cycle
+of interaction with the user. If you call <CODE>update_panels()</CODE> after
+each and every panel write, you'll generate a lot of unnecessary refresh
+activity and screen flicker. <P>
+
+<H2><A NAME="pstdscr">Panels, Input, and the Standard Screen</A></H2>
+
+You shouldn't mix <CODE>wnoutrefresh()</CODE> or <CODE>wrefresh()</CODE>
+operations with panels code; this will work only if the argument window
+is either in the top panel or unobscured by any other panels. <P>
+
+The <CODE>stsdcr</CODE> window is a special case. It is considered below all
+panels. Because changes to panels may obscure parts of <CODE>stdscr</CODE>,
+though, you should call <CODE>update_panels()</CODE> before
+<CODE>doupdate()</CODE> even when you only change <CODE>stdscr</CODE>. <P>
+
+Note that <CODE>wgetch</CODE> automatically calls <CODE>wrefresh</CODE>.
+Therefore, before requesting input from a panel window, you need to be sure
+that the panel is totally unobscured. <P>
+
+There is presently no way to display changes to one obscured panel without
+repainting all panels. <P>
+
+<H2><A NAME="hiding">Hiding Panels</A></H2>
+
+It's possible to remove a panel from the deck temporarily; use
+<CODE>hide_panel</CODE> for this. Use <CODE>show_panel()</CODE> to render it
+visible again. The predicate function <CODE>panel_hidden</CODE>
+tests whether or not a panel is hidden. <P>
+
+The <CODE>panel_update</CODE> code ignores hidden panels. You cannot do
+<CODE>top_panel()</CODE> or <CODE>bottom_panel</CODE> on a hidden panel().
+Other panels operations are applicable. <P>
+
+<H2><A NAME="pmisc">Miscellaneous Other Facilities</A></H2>
+
+It's possible to navigate the deck using the functions
+<CODE>panel_above()</CODE> and <CODE>panel_below</CODE>. Handed a panel
+pointer, they return the panel above or below that panel. Handed
+<CODE>NULL</CODE>, they return the bottom-most or top-most panel. <P>
+
+Every panel has an associated user pointer, not used by the panel code, to
+which you can attach application data. See the man page documentation
+of <CODE>set_panel_userptr()</CODE> and <CODE>panel_userptr</CODE> for
+details. <P>
+
+<H1><A NAME="menu">The Menu Library</A></H1>
+
+A menu is a screen display that assists the user to choose some subset
+of a given set of items. The <CODE>menu</CODE> library is a curses
+extension that supports easy programming of menu hierarchies with a
+uniform but flexible interface. <P>
+
+The <CODE>menu</CODE> library first appeared in AT&amp;T System V. The
+version documented here is the <CODE>menu</CODE> code distributed
+with <CODE>ncurses</CODE>. <P>
+
+<H2><A NAME="mcompile">Compiling With the menu Library</A></H2>
+
+Your menu-using modules must import the menu library declarations with
+
+<PRE>
+ #include &lt;menu.h&gt;
+</PRE>
+
+and must be linked explicitly with the menus library using an
+<CODE>-lmenu</CODE> argument. Note that they must also link the
+<CODE>ncurses</CODE> library with <CODE>-lncurses</CODE>. Many linkers
+are two-pass and will accept either order, but it is still good practice
+to put <CODE>-lmenu</CODE> first and <CODE>-lncurses</CODE> second.
+
+<H2><A NAME="moverview">Overview of Menus</A></H2>
+
+The menus created by this library consist of collections of
+<DFN>items</DFN> including a name string part and a description string
+part. To make menus, you create groups of these items and connect
+them with menu frame objects. <P>
+
+The menu can then by <DFN>posted</DFN>, that is written to an
+associated window. Actually, each menu has two associated windows; a
+containing window in which the programmer can scribble titles or
+borders, and a subwindow in which the menu items proper are displayed.
+If this subwindow is too small to display all the items, it will be a
+scrollable viewport on the collection of items. <P>
+
+A menu may also be <DFN>unposted</DFN> (that is, undisplayed), and finally
+freed to make the storage associated with it and its items available for
+re-use. <P>
+
+The general flow of control of a menu program looks like this:
+
+<OL>
+<LI>Initialize <CODE>curses</CODE>.
+<LI>Create the menu items, using <CODE>new_item()</CODE>.
+<LI>Create the menu using <CODE>new_menu()</CODE>.
+<LI>Post the menu using <CODE>menu_post()</CODE>.
+<LI>Refresh the screen.
+<LI>Process user requests via an input loop.
+<LI>Unpost the menu using <CODE>menu_unpost()</CODE>.
+<LI>Free the menu, using <CODE>free_menu()</CODE>.
+<LI>Free the items using <CODE>free_item()</CODE>.
+<LI>Terminate <CODE>curses</CODE>.
+</OL>
+
+<H2><A NAME="mselect">Selecting items</A></H2>
+
+Menus may be multi-valued or (the default) single-valued (see the manual
+page <CODE>menu_opts(3x)</CODE> to see how to change the default).
+Both types always have a <DFN>current item</DFN>. <P>
+
+From a single-valued menu you can read the selected value simply by looking
+at the current item. From a multi-valued menu, you get the selected set
+by looping through the items applying the <CODE>item_value()</CODE>
+predicate function. Your menu-processing code can use the function
+<CODE>set_item_value()</CODE> to flag the items in the select set. <P>
+
+Menu items can be made unselectable using <CODE>set_item_opts()</CODE>
+or <CODE>item_opts_off()</CODE> with the <CODE>O_SELECTABLE</CODE>
+argument. This is the only option so far defined for menus, but it
+is good practice to code as though other option bits might be on. <P>
+
+<H2><A NAME="mdisplay">Menu Display</A></H2>
+
+The menu library calculates a minimum display size for your window, based
+on the following variables: <P>
+
+<UL>
+<LI>The number and maximum length of the menu items
+<LI>Whether the O_ROWMAJOR option is enabled
+<LI>Whether display of descriptions is enabled
+<LI>Whatever menu format may have been set by the programmer
+<LI>The length of the menu mark string used for highlighting selected items
+</UL>
+
+The function <CODE>set_menu_format()</CODE> allows you to set the
+maximum size of the viewport or <DFN>menu page</DFN> that will be used
+to display menu items. You can retrieve any format associated with a
+menu with <CODE>menu_format()</CODE>. The default format is rows=16,
+columns=1. <P>
+
+The actual menu page may be smaller than the format size. This depends
+on the item number and size and whether O_ROWMAJOR is on. This option
+(on by default) causes menu items to be displayed in a `raster-scan'
+pattern, so that if more than one item will fit horizontally the first
+couple of items are side-by-side in the top row. The alternative is
+column-major display, which tries to put the first several items in
+the first column. <P>
+
+As mentioned above, a menu format not large enough to allow all items to fit
+on-screen will result in a menu display that is vertically scrollable. <P>
+You can scroll it with requests to the menu driver, which will be described
+in the section on <A HREF="#minput">menu input handling</A>. <P>
+
+Each menu has a <DFN>mark string</DFN> used to visually tag selected items;
+see the <CODE>menu_mark(3x)</CODE> manual page for details. The mark
+string length also influences the menu page size. <P>
+
+The function <CODE>scale_menu()</CODE> returns the minimum display size
+that the menu code computes from all these factors.
+
+There are other menu display attributes including a select attribute,
+an attribute for selectable items, an attribute for unselectable items,
+and a pad character used to separate item name text from description
+text. These have reasonable defaults which the library allows you to
+change (see the <CODE>menu_attribs(3x)</CODE> manual page. <P>
+
+<H2><A NAME="mwindows">Menu Windows</A></H2>
+
+Each menu has, as mentioned previously, a pair of associated windows.
+Both these windows are painted when the menu is posted and erased when
+the menu is unposted. <P>
+
+The outer or frame window is not otherwise touched by the menu
+routines. It exists so the programmer can associate a title, a
+border, or perhaps help text with the menu and have it properly
+refreshed or erased at post/unpost time. The inner window or
+<DFN>subwindow</DFN> is where the current menu page is displayed. <P>
+
+By default, both windows are <CODE>stdscr</CODE>. You can set them with the
+functions in <CODE>menu_win(3x)</CODE>. <P>
+
+When you call <CODE>menu_post()</CODE>, you write the menu to its
+subwindow. When you call <CODE>menu_unpost()</CODE>, you erase the
+subwindow, However, neither of these actually modifies the screen. To
+do that, call <CODE>wrefresh()</CODE> or some equivalent. <P>
+
+<H2><A NAME="minput">Processing Menu Input</A></H2>
+
+The main loop of your menu-processing code should call
+<CODE>menu_driver()</CODE> repeatedly. The first argument of this routine
+is a menu pointer; the second is a menu command code. You should write an
+input-fetching routine that maps input characters to menu command codes, and
+pass its output to <CODE>menu_driver()</CODE>. The menu command codes are
+fully documented in <CODE>menu_driver(3x)</CODE>. <P>
+
+The simplest group of command codes is <CODE>REQ_NEXT_ITEM</CODE>,
+<CODE>REQ_PREV_ITEM</CODE>, <CODE>REQ_FIRST_ITEM</CODE>,
+<CODE>REQ_LAST_ITEM</CODE>, <CODE>REQ_UP_ITEM</CODE>,
+<CODE>REQ_DOWN_ITEM</CODE>, <CODE>REQ_LEFT_ITEM</CODE>,
+<CODE>REQ_RIGHT_ITEM</CODE>. These change the currently selected
+item. These requests may cause scrolling of the menu page if it only
+partially displayed. <P>
+
+There are explicit requests for scrolling which also change the
+current item (because the select location does not change, but the
+item there does). These are <CODE>REQ_SCR_DLINE</CODE>,
+<CODE>REQ_SCR_ULINE</CODE>, <CODE>REQ_SCR_DPAGE</CODE>, and
+<CODE>REQ_SCR_UPAGE</CODE>. <P>
+
+The <CODE>REQ_TOGGLE_ITEM</CODE> selects or deselects the current item.
+It is for use in multi-valued menus; if you use it with <CODE>O_ONEVALUE</CODE>
+on, you'll get an error return (<CODE>E_REQUEST_DENIED</CODE>). <P>
+
+Each menu has an associated pattern buffer. The
+<CODE>menu_driver()</CODE> logic tries to accumulate printable ASCII
+characters passed in in that buffer; when it matches a prefix of an
+item name, that item (or the next matching item) is selected. If
+appending a character yields no new match, that character is deleted
+from the pattern buffer, and <CODE>menu_driver()</CODE> returns
+<CODE>E_NO_MATCH</CODE>. <P>
+
+Some requests change the pattern buffer directly:
+<CODE>REQ_CLEAR_PATTERN</CODE>, <CODE>REQ_BACK_PATTERN</CODE>,
+<CODE>REQ_NEXT_MATCH</CODE>, <CODE>REQ_PREV_MATCH</CODE>. The latter
+two are useful when pattern buffer input matches more than one item
+in a multi-valued menu. <P>
+
+Each successful scroll or item navigation request clears the pattern
+buffer. It is also possible to set the pattern buffer explicitly
+with <CODE>set_menu_pattern()</CODE>. <P>
+
+Finally, menu driver requests above the constant <CODE>MAX_COMMAND</CODE>
+are considered application-specific commands. The <CODE>menu_driver()</CODE>
+code ignores them and returns <CODE>E_UNKNOWN_COMMAND</CODE>.
+
+<H2><A NAME="mmisc">Miscellaneous Other Features</A></H2>
+
+Various menu options can affect the processing and visual appearance
+and input processing of menus. See <CODE>menu_opts(3x) for
+details.</CODE> <P>
+
+It is possible to change the current item from application code; this
+is useful if you want to write your own navigation requests. It is
+also possible to explicitly set the top row of the menu display. See
+<CODE>mitem_current(3x)</CODE>.
+
+If your application needs to change the menu subwindow cursor for
+any reason, <CODE>pos_menu_cursor()</CODE> will restore it to the
+correct location for continuing menu driver processing. <P>
+
+It is possible to set hooks to be called at menu initialization and
+wrapup time, and whenever the selected item changes. See
+<CODE>menu_hook(3x)</CODE>. <P>
+
+Each item, and each menu, has an associated user pointer on which you
+can hang application data. See <CODE>mitem_userptr(3x)</CODE> and
+<CODE>menu_userptr(3x)</CODE>. <P>
+
+<H1><A NAME="form">The Forms Library</A></H1>
+
+The <CODE>form</CODE> library is a curses extension that supports easy
+programming of on-screen forms for data entry and program control. <P>
+
+The <CODE>form</CODE> library first appeared in AT&amp;T System V. The
+version documented here is the <CODE>form</CODE> code distributed
+with <CODE>ncurses</CODE>. <P>
+
+<H2><A NAME="fcompile">Compiling With the form Library</A></H2>
+
+Your form-using modules must import the form library declarations with
+
+<PRE>
+ #include &lt;form.h&gt;
+</PRE>
+
+and must be linked explicitly with the forms library using an
+<CODE>-lform</CODE> argument. Note that they must also link the
+<CODE>ncurses</CODE> library with <CODE>-lncurses</CODE>. Many linkers
+are two-pass and will accept either order, but it is still good practice
+to put <CODE>-lform</CODE> first and <CODE>-lncurses</CODE> second. <P>
+
+<H2><A NAME="foverview">Overview of Forms</A></H2>
+
+A form is a collection of fields; each field may be either a label
+(explanatory text) or a data-entry location. Long forms may be
+segmented into pages; each entry to a new page clears the screen. <P>
+To make forms, you create groups of fields and connect them with form
+frame objects; the form library makes this relatively simple. <P>
+
+Once defined, a form can be <DFN>posted</DFN>, that is written to an
+associated window. Actually, each form has two associated windows; a
+containing window in which the programmer can scribble titles or
+borders, and a subwindow in which the form fields proper are displayed. <P>
+
+As the form user fills out the posted form, navigation and editing
+keys support movement between fields, editing keys support modifying
+field, and plain text adds to or changes data in a current field. The
+form library allows you (the forms designer) to bind each navigation
+and editing key to any keystroke accepted by <CODE>curses</CODE>
+
+Fields may have validation conditions on them, so that they check input
+data for type and value. The form library supplies a rich set of
+pre-defined field types, and makes it relatively easy to define new ones. <P>
+
+Once its transaction is completed (or aborted), a form may be
+<DFN>unposted</DFN> (that is, undisplayed), and finally freed to make
+the storage associated with it and its items available for re-use. <P>
+
+The general flow of control of a form program looks like this:
+
+<OL>
+<LI>Initialize <CODE>curses</CODE>.
+<LI>Create the form fields, using <CODE>new_field()</CODE>.
+<LI>Create the form using <CODE>new_form()</CODE>.
+<LI>Post the form using <CODE>form_post()</CODE>.
+<LI>Refresh the screen.
+<LI>Process user requests via an input loop.
+<LI>Unpost the form using <CODE>form_unpost()</CODE>.
+<LI>Free the form, using <CODE>free_form()</CODE>.
+<LI>Free the fields using <CODE>free_field()</CODE>.
+<LI>Terminate <CODE>curses</CODE>.
+</OL>
+
+Note that this looks much like a menu program; the form library handles
+tasks which are in many ways similar, and its interface was obviously
+designed to resemble that of the <A HREF="#menu">menu library</A>
+wherever possible. <P>
+
+In forms programs, however, the `process user requests' is somewhat more
+complicated than for menus. Besides menu-like navigation operations,
+the menu driver loop has to support field editing and data validation. <P>
+
+<H2><A NAME="fcreate">Creating and Freeing Fields and Forms</A></H2>
+
+The basic function for creating fields is <CODE>new_field()</CODE>: <P>
+
+<PRE>
+FIELD *new_field(int height, int width, /* new field size */
+ int top, int left, /* upper left corner */
+ int offscreen, /* number of offscreen rows */
+ int nbuf); /* number of working buffers */
+</PRE>
+
+Menu items always occupy a single row, but forms fields may have
+multiple rows. So <CODE>new_field()</CODE> requires you to specify a
+width and height (the first two arguments, which mist both be greater
+than zero). <P>
+
+You must also specify the location of the field's upper left corner on
+the screen (the third and fourth arguments, which must be zero or
+greater). Note that these coordinates are relative to the form
+subwindow, which will coincide with <CODE>stdscr</CODE> by default but
+need not be <CODE>stdscr</CODE> if you've done an explicit
+<CODE>set_form_window()</CODE> call. <P>
+
+The fifth argument allows you to specify a number of off-screen rows. If
+this is zero, the entire field will always be displayed. If it is
+nonzero, the form will be scrollable, with only one screen-full (initially
+the top part) displayed at any given time. If you make a field dynamic
+and grow it so it will no longer fit on the screen, the form will become
+scrollable even if the <CODE>offscreen</CODE> argument was initially zero. <P>
+
+The forms library allocates one working buffer per field; the size of
+each buffer is <CODE>((height + offscreen)*width + 1</CODE>, one character
+for each position in the field plus a NUL terminator. The sixth
+argument is the number of additional data buffers to allocate for the
+field; your application can use them for its own purposes. <P>
+
+<PRE>
+FIELD *dup_field(FIELD *field, /* field to copy */
+ int top, int left); /* location of new copy */
+</PRE>
+
+The function <CODE>dup_field()</CODE> duplicates an existing field at a
+new location. Size and buffering information are copied; some
+attribute flags and status bits are not (see the
+<CODE>form_field_new(3X)</CODE> for details). <P>
+
+<PRE>
+FIELD *link_field(FIELD *field, /* field to copy */
+ int top, int left); /* location of new copy */
+</PRE>
+
+The function <CODE>link_field()</CODE> also duplicates an existing field
+at a new location. The difference from <CODE>dup_field()</CODE> is that
+it arranges for the new field's buffer to be shared with the old one. <P>
+
+Besides the obvious use in making a field editable from two different
+form pages, linked fields give you a way to hack in dynamic labels. If
+you declare several fields linked to an original, and then make them
+inactive, changes from the original will still be propagated to the
+linked fields. <P>
+
+As with duplicated fields, linked fields have attribute bits separate
+from the original. <P>
+
+As you might guess, all these field-allocations return <CODE>NULL</CODE> if
+the field allocation is not possible due to an out-of-memory error or
+out-of-bounds arguments. <P>
+
+To connect fields to a form, use <P>
+
+<PRE>
+FORM *new_form(FIELD **fields);
+</PRE>
+
+This function expects to see a NULL-terminated array of field pointers.
+Said fields are connected to a newly-allocated form object; its address
+is returned (or else NULL if the allocation fails). <P>
+
+Note that <CODE>new_field()</CODE> does <EM>not</EM> copy the pointer array
+into private storage; if you modify the contents of the pointer array
+during forms processing, all manner of bizarre things might happen. Also
+note that any given field may only be connected to one form. <P>
+
+The functions <CODE>free_field()</CODE> and <CODE>free_form</CODE> are available
+to free field and form objects. It is an error to attempt to free a field
+connected to a form, but not vice-versa; thus, you will generally free
+your form objects first. <P>
+
+<H2><A NAME="fattributes">Fetching and Changing Field Attributes</A></H2>
+
+Each form field has a number of location and size attributes
+associated with it. There are other field attributes used to control
+display and editing of the field. Some (for example, the <CODE>O_STATIC</CODE> bit)
+involve sufficient complications to be covered in sections of their own
+later on. We cover the functions used to get and set several basic
+attributes here. <P>
+
+When a field is created, the attributes not specified by the
+<CODE>new_field</CODE> function are copied from an invisible system
+default field. In attribute-setting and -fetching functions, the
+argument NULL is taken to mean this field. Changes to it persist
+as defaults until your forms application terminates. <P>
+
+<H3><A NAME="fsizes">Fetching Size and Location Data</A></H3>
+
+You can retrieve field sizes and locations through: <P>
+
+<PRE>
+int field_info(FIELD *field, /* field from which to fetch */
+ int *height, *int width, /* field size */
+ int *top, int *left, /* upper left corner */
+ int *offscreen, /* number of offscreen rows */
+ int *nbuf); /* number of working buffers */
+</PRE>
+
+This function is a sort of inverse of <CODE>new_field()</CODE>; instead of
+setting size and location attributes of a new field, it fetches them
+from an existing one. <P>
+
+<H3><A NAME="flocation">Changing the Field Location</A></H3>
+
+It is possible to move a field's location on the screen: <P>
+
+<PRE>
+int move_field(FIELD *field, /* field to alter */
+ int top, int left); /* new upper-left corner */
+</PRE>
+
+You can, of course. query the current location through <CODE>field_info()</CODE>.
+
+<H3><A NAME="fjust">The Justification Attribute</A></H3>
+
+One-line fields may be unjustified, justified right, justified left,
+or centered. Here is how you manipulate this attribute: <P>
+
+<PRE>
+int set_field_just(FIELD *field, /* field to alter */
+ int justmode); /* mode to set */
+
+int field_just(FIELD *field); /* fetch mode of field */
+</PRE>
+
+The mode values accepted and returned by this functions are
+preprocessor macros <CODE>NO_JUSTIFICATION</CODE>, <CODE>JUSTIFY_RIGHT</CODE>,
+<CODE>JUSTIFY_LEFT</CODE>, or <CODE>JUSTIFY_CENTER</CODE>. <P>
+
+<H3><A NAME="fdispatts">Field Display Attributes</A></H3>
+
+For each field, you can set a foreground attribute for entered
+characters, a background attribute for the entire field, and a pad
+character for the unfilled portion of the field. You can also
+control pagination of the form. <P>
+
+This group of four field attributes controls the visual appearance
+of the field on the screen, without affecting in any way the data
+in the field buffer. <P>
+
+<PRE>
+int set_field_fore(FIELD *field, /* field to alter */
+ chtype attr); /* attribute to set */
+
+chtype field_fore(FIELD *field); /* field to query */
+
+int set_field_back(FIELD *field, /* field to alter */
+ chtype attr); /* attribute to set */
+
+chtype field_back(FIELD *field); /* field to query */
+
+int set_field_pad(FIELD *field, /* field to alter */
+ int pad); /* pad character to set */
+
+chtype field_pad(FIELD *field);
+
+int set_new_page(FIELD *field, /* field to alter */
+ int flag); /* TRUE to force new page */
+
+chtype new_page(FIELD *field); /* field to query */
+</PRE>
+
+The attributes set and returned by the first four functions are normal
+<CODE>curses(3x)</CODE> display attribute values (<CODE>A_STANDOUT</CODE>,
+<CODE>A_BOLD</CODE>, <CODE>A_REVERSE</CODE> etc).
+
+The page bit of a field controls whether it is displayed at the start of
+a new form screen. <P>
+
+<H3><A NAME="foptions">Field Option Bits</A></H3>
+
+There is also a large collection of field option bits you can set to control
+various aspects of forms processing. You can manipulate them with these
+functions:
+
+<PRE>
+int set_field_opts(FIELD *field, /* field to alter */
+ int attr); /* attribute to set */
+
+int field_opts_on(FIELD *field, /* field to alter */
+ int attr); /* attributes to turn on */
+
+int field_opts_off(FIELD *field, /* field to alter */
+ int attr); /* attributes to turn off */
+
+int field_opts(FIELD *field); /* field to query */
+</PRE>
+
+By default, all options are on. Here are the available option bits:
+<DL>
+<DT> O_VISIBLE
+<DD> Controls whether the field is visible on the screen. Can be used
+during form processing to hide or pop up fields depending on the value
+of parent fields.
+<DT> O_ACTIVE
+<DD> Controls whether the field is active during forms processing (i.e.
+visited by form navigation keys). Can be used to make labels or derived
+fields with buffer values alterable by the forms application, not the user.
+<DT> O_PUBLIC
+<DD> Controls whether data is displayed during field entry. If this option is
+turned off on a field, the library will accept and edit data in that field,
+but it will not be displayed and the visible field cursor will not move.
+You can turn off the O_PUBLIC bit to define password fields.
+<DT> O_EDIT
+<DD> Controls whether the field's data can be modified. When this option is
+off, all editing requests except <CODE>REQ_PREV_CHOICE</CODE> and
+<CODE>REQ_NEXT_CHOICE</CODE> will fail. Such read-only fields may be useful for
+help messages.
+<DT> O_WRAP
+<DD> Controls word-wrapping in multi-line fields. Normally, when any
+character of a (blank-separated) word reaches the end of the current line, the
+entire word is wrapped to the next line (assuming there is one). When this
+option is off, the word will be split across the line break.
+<DT> O_BLANK
+<DD> Controls field blanking. When this option is on, entering a character at
+the first field position erases the entire field (except for the just-entered
+character).
+<DT> O_AUTOSKIP
+<DD> Controls automatic skip to next field when this one fills. Normally,
+when the forms user tries to type more data into a field than will fit,
+the editing location jumps to next field. When this option is off, the
+user's cursor will hang at the end of the field. This option is ignored
+in dynamic fields that have not reached their size limit.
+<DT> O_NULLOK
+<DD> Controls whether <A HREF="#fvalidation">validation</A> is applied to
+blank fields. Normally, it is not; the user can leave a field blank
+without invoking the usual validation check on exit. If this option is
+off on a field, exit from it will invoke a validation check.
+<DT> O_PASSOK
+<DD> Controls whether validation occurs on every exit, or only after
+the field is modified. Normally the latter is true. Setting O_PASSOK
+may be useful if your field's validation function may change during
+forms processing.
+<DT> O_STATIC
+<DD> Controls whether the field is fixed to its initial dimensions. If you
+turn this off, the field becomes <A HREF="#fdynamic">dynamic</A> and will
+stretch to fit entered data.
+</DL>
+
+A field's options cannot be changed while the field is currently selected.
+However, options may be changed on posted fields that are not current. <P>
+
+The option values are bit-masks and can be composed with logical-or in
+the obvious way. <P>
+
+<H2><A NAME="fstatus">Field Status</A></H2>
+
+Every field has a status flag, which is set to FALSE when the field is
+created and TRUE when the value in field buffer 0 changes. This flag can
+be queried and set directly: <P>
+
+<PRE>
+int set_field_status(FIELD *field, /* field to alter */
+ int status); /* mode to set */
+
+int field_status(FIELD *field); /* fetch mode of field */
+</PRE>
+
+Setting this flag under program control can be useful if you use the same
+form repeatedly, looking for modified fields each time. <P>
+
+Calling <CODE>field_status()</CODE> on a field not currently selected
+for input will return a correct value. Calling <CODE>field_status()</CODE> on a
+field that is currently selected for input may not necessarily give a
+correct field status value, because entered data isn't necessarily copied to
+buffer zero before the exit validation check.
+
+To guarantee that the returned status value reflects reality, call
+<CODE>field_status()</CODE> either (1) in the field's exit validation check
+routine, (2) from the field's or form's initialization or termination
+hooks, or (3) just after a <CODE>REQ_VALIDATION</CODE> request has been
+processed by the forms driver. <P>
+
+<H2><A NAME="fuser">Field User Pointer</A></H2>
+
+Each field structure contains one character pointer slot that is not used
+by the forms library. It is intended to be used by applications to store
+private per-field data. You can manipulate it with:
+
+<PRE>
+int set_field_userptr(FIELD *field, /* field to alter */
+ char *userptr); /* mode to set */
+
+char *field_userptr(FIELD *field); /* fetch mode of field */
+</PRE>
+
+(Properly, this user pointer field ought to have <CODE>(void *)</CODE> type.
+The <CODE>(char *)</CODE> type is retained for System V compatibility.) <P>
+
+It is valid to set the user pointer of the default field (with a
+<CODE>set_field_userptr()</CODE> call passed a NULL field pointer.)
+When a new field is created, the default-field user pointer is copied
+to initialize the new field's user pointer. <P>
+
+<H2><A NAME="fdynamic">Variable-Sized Fields</A></H2>
+
+Normally, a field is fixed at the size specified for it at creation
+time. If, however, you turn off its O_STATIC bit, it becomes
+<DFN>dynamic</DFN> and will automatically resize itself to accommodate
+data as it is entered. If the field has extra buffers associated with it,
+they will grow right along with the main input buffer. <P>
+
+A one-line dynamic field will have a fixed height (1) but variable
+width, scrolling horizontally to display data within the field area as
+originally dimensioned and located. A multi-line dynamic field will
+have a fixed width, but variable height (number of rows), scrolling
+vertically to display data within the field area as originally
+dimensioned and located. <P>
+
+Normally, a dynamic field is allowed to grow without limit. But it is
+possible to set an upper limit on the size of a dynamic field. You do
+it with this function: <P>
+
+<PRE>
+int set_max_field(FIELD *field, /* field to alter (may not be NULL) */
+ int max_size); /* upper limit on field size */
+</PRE>
+
+If the field is one-line, <CODE>max_size</CODE> is taken to be a column size
+limit; if it is multi-line, it is taken to be a line size limit. To disable
+any limit, use an argument of zero. The growth limit can be changed whether
+or not the O_STATIC bit is on, but has no effect until it is. <P>
+
+The following properties of a field change when it becomes dynamic:
+
+<UL>
+<LI>If there is no growth limit, there is no final position of the field;
+therefore <CODE>O_AUTOSKIP</CODE> and <CODE>O_NL_OVERLOAD</CODE> are ignored.
+<LI>Field justification will be ignored (though whatever justification is
+set up will be retained internally and can be queried).
+<LI>The <CODE>dup_field()</CODE> and <CODE>link_field()</CODE> calls copy
+dynamic-buffer sizes. If the <CODE>O_STATIC</CODE> option is set on one of a
+collection of links, buffer resizing will occur only when the field is
+edited through that link.
+<LI>The call <CODE>field_info()</CODE> will retrieve the original static size of
+the field; use <CODE>dynamic_field_info()</CODE> to get the actual dynamic size.
+</UL>
+
+<H2><A NAME="fvalidation">Field Validation</A></H2>
+
+By default, a field will accept any data that will fit in its input buffer.
+However, it is possible to attach a validation type to a field. If you do
+this, any attempt to leave the field while it contains data that doesn't
+match the validation type will fail. Some validation types also have a
+character-validity check for each time a character is entered in the field. <P>
+
+A field's validation check (if any) is not called when
+<CODE>set_field_buffer()</CODE> modifies the input buffer, nor when that buffer
+is changed through a linked field. <P>
+
+The <CODE>form</CODE> library provides a rich set of pre-defined validation
+types, and gives you the capability to define custom ones of your own. You
+can examine and change field validation attributes with the following
+functions: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ FIELDTYPE *ftype, /* type to associate */
+ ...); /* additional arguments*/
+
+FIELDTYPE *field_type(FIELD *field); /* field to query */
+</PRE>
+
+The validation type of a field is considered an attribute of the field. As
+with other field attributes, Also, doing <CODE>set_field_type()</CODE> with a
+<CODE>NULL</CODE> field default will change the system default for validation of
+newly-created fields. <P>
+
+Here are the pre-defined validation types: <P>
+
+<H3><A NAME="ftype_alpha">TYPE_ALPHA</A></H3>
+
+This field type accepts alphabetic data; no blanks, no digits, no special
+characters (this is checked at character-entry time). It is set up with: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_ALPHA, /* type to associate */
+ int width); /* maximum width of field */
+</PRE>
+
+The <CODE>width</CODE> argument sets a minimum width of data. Typically
+you'll want to set this to the field width; if it's greater than the
+field width, the validation check will always fail. A minimum width
+of zero makes field completion optional. <P>
+
+<H3><A NAME="ftype_alnum">TYPE_ALNUM</A></H3>
+
+This field type accepts alphabetic data and digits; no blanks, no special
+characters (this is checked at character-entry time). It is set up with: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_ALNUM, /* type to associate */
+ int width); /* maximum width of field */
+</PRE>
+
+The <CODE>width</CODE> argument sets a minimum width of data. As with
+TYPE_ALPHA, typically you'll want to set this to the field width; if it's
+greater than the field width, the validation check will always fail. A
+minimum width of zero makes field completion optional. <P>
+
+<H3><A NAME="ftype_enum">TYPE_ENUM</A></H3>
+
+This type allows you to restrict a field's values to be among a specified
+set of string values (for example, the two-letter postal codes for U.S.
+states). It is set up with: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_ENUM, /* type to associate */
+ char **valuelist; /* list of possible values */
+ int checkcase; /* case-sensitive? */
+ int checkunique); /* must specify uniquely? */
+</PRE>
+
+The <CODE>valuelist</CODE> parameter must point at a NULL-terminated list of
+valid strings. The <CODE>checkcase</CODE> argument, if true, makes comparison
+with the string case-sensitive. <P>
+
+When the user exits a TYPE_ENUM field, the validation procedure tries to
+complete the data in the buffer to a valid entry. If a complete choice string
+has been entered, it is of course valid. But it is also possible to enter a
+prefix of a valid string and have it completed for you. <P>
+
+By default, if you enter such a prefix and it matches more than one value
+in the string list, the prefix will be completed to the first matching
+value. But the <CODE>checkunique</CODE> argument, if true, requires prefix
+matches to be unique in order to be valid. <P>
+
+The <CODE>REQ_NEXT_CHOICE</CODE> and <CODE>REQ_PREV_CHOICE</CODE> input requests
+can be particularly useful with these fields. <P>
+
+<H3><A NAME="ftype_integer">TYPE_INTEGER</A></H3>
+
+This field type accepts an integer. It is set up as follows: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_INTEGER, /* type to associate */
+ int padding, /* # places to zero-pad to */
+ int vmin, int vmax); /* valid range */
+</PRE>
+
+Valid characters consist of an optional leading minus and digits.
+The range check is performed on exit. If the range maximum is less
+than or equal to the minimum, the range is ignored. <P>
+
+If the value passes its range check, it is padded with as many leading
+zero digits as necessary to meet the padding argument. <P>
+
+A <CODE>TYPE_INTEGER</CODE> value buffer can conveniently be interpreted
+with the C library function <CODE>atoi(3)</CODE>.
+
+<H3><A NAME="ftype_numeric">TYPE_NUMERIC</A></H3>
+
+This field type accepts a decimal number. It is set up as follows: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_NUMERIC, /* type to associate */
+ int padding, /* # places of precision */
+ double vmin, double vmax); /* valid range */
+</PRE>
+
+Valid characters consist of an optional leading minus and digits. possibly
+including a decimal point. If your system supports locale's, the decimal point
+character used must be the one defined by your locale. The range check is
+performed on exit. If the range maximum is less than or equal to the minimum,
+the range is ignored. <P>
+
+If the value passes its range check, it is padded with as many trailing
+zero digits as necessary to meet the padding argument. <P>
+
+A <CODE>TYPE_NUMERIC</CODE> value buffer can conveniently be interpreted
+with the C library function <CODE>atof(3)</CODE>.
+
+<H3><A NAME="ftype_regexp">TYPE_REGEXP</A></H3>
+
+This field type accepts data matching a regular expression. It is set up
+as follows: <P>
+
+<PRE>
+int set_field_type(FIELD *field, /* field to alter */
+ TYPE_REGEXP, /* type to associate */
+ char *regexp); /* expression to match */
+</PRE>
+
+The syntax for regular expressions is that of <CODE>regcomp(3)</CODE>.
+The check for regular-expression match is performed on exit.
+
+<H2><A NAME="fbuffer">Direct Field Buffer Manipulation</A></H2>
+
+The chief attribute of a field is its buffer contents. When a form has
+been completed, your application usually needs to know the state of each
+field buffer. You can find this out with: <P>
+
+<PRE>
+char *field_buffer(FIELD *field, /* field to query */
+ int bufindex); /* number of buffer to query */
+</PRE>
+
+Normally, the state of the zero-numbered buffer for each field is set by
+the user's editing actions on that field. It's sometimes useful to be able
+to set the value of the zero-numbered (or some other) buffer from your
+application:
+
+<PRE>
+int set_field_buffer(FIELD *field, /* field to alter */
+ int bufindex, /* number of buffer to alter */
+ char *value); /* string value to set */
+</PRE>
+
+If the field is not large enough and cannot be resized to a sufficiently
+large size to contain the specified value, the value will be truncated
+to fit. <P>
+
+Calling <CODE>field_buffer()</CODE> with a null field pointer will raise an
+error. Calling <CODE>field_buffer()</CODE> on a field not currently selected
+for input will return a correct value. Calling <CODE>field_buffer()</CODE> on a
+field that is currently selected for input may not necessarily give a
+correct field buffer value, because entered data isn't necessarily copied to
+buffer zero before the exit validation check.
+
+To guarantee that the returned buffer value reflects on-screen reality,
+call <CODE>field_buffer()</CODE> either (1) in the field's exit validation
+check routine, (2) from the field's or form's initialization or termination
+hooks, or (3) just after a <CODE>REQ_VALIDATION</CODE> request has been processed
+by the forms driver. <P>
+
+<H2><A NAME="formattrs">Attributes of Forms</A></H2>
+
+As with field attributes, form attributes inherit a default from a
+system default form structure. These defaults can be queried or set by
+of these functions using a form-pointer argument of <CODE>NULL</CODE>. <P>
+
+The principal attribute of a form is its field list. You can query
+and change this list with: <P>
+
+<PRE>
+int set_form_fields(FORM *form, /* form to alter */
+ FIELD **fields); /* fields to connect */
+
+char *form_fields(FORM *form); /* fetch fields of form */
+
+int field_count(FORM *form); /* count connect fields */
+</PRE>
+
+The second argument of <CODE>set_form_fields()</CODE> may be a
+NULL-terminated field pointer array like the one required by
+<CODE>new_form()</CODE>. In that case, the old fields of the form are
+disconnected but not freed (and eligible to be connected to other
+forms), then the new fields are connected. <P>
+
+It may also be null, in which case the old fields are disconnected
+(and not freed) but no new ones are connected. <P>
+
+The <CODE>field_count()</CODE> function simply counts the number of fields
+connected to a given from. It returns -1 if the form-pointer argument
+is NULL. <P>
+
+<H2><A NAME="fdisplay">Control of Form Display</A></H2>
+
+In the overview section, you saw that to display a form you normally
+start by defining its size (and fields), posting it, and refreshing
+the screen. There is an hidden step before posting, which is the
+association of the form with a frame window (actually, a pair of
+windows) within which it will be displayed. By default, the forms
+library associates every form with the full-screen window
+<CODE>stdscr</CODE>. <P>
+
+By making this step explicit, you can associate a form with a declared
+frame window on your screen display. This can be useful if you want to
+adapt the form display to different screen sizes, dynamically tile
+forms on the screen, or use a form as part of an interface layout
+managed by <A HREF="#panels">panels</A>. <P>
+
+The two windows associated with each form have the same functions as
+their analogues in the <A HREF="#menu">menu library</A>. Both these
+windows are painted when the form is posted and erased when the form
+is unposted. <P>
+
+The outer or frame window is not otherwise touched by the form
+routines. It exists so the programmer can associate a title, a
+border, or perhaps help text with the form and have it properly
+refreshed or erased at post/unpost time. The inner window or subwindow
+is where the current form page is actually displayed. <P>
+
+In order to declare your own frame window for a form, you'll need to
+know the size of the form's bounding rectangle. You can get this
+information with: <P>
+
+<PRE>
+int scale_form(FORM *form, /* form to query */
+ int *rows, /* form rows */
+ int *cols); /* form cols */
+</PRE>
+
+The form dimensions are passed back in the locations pointed to by
+the arguments. Once you have this information, you can use it to
+declare of windows, then use one of these functions:
+
+<PRE>
+int set_form_win(FORM *form, /* form to alter */
+ WINDOW *win); /* frame window to connect */
+
+WINDOW *form_win(FORM *form); /* fetch frame window of form */
+
+int set_form_sub(FORM *form, /* form to alter */
+ WINDOW *win); /* form subwindow to connect */
+
+WINDOW *form_sub(FORM *form); /* fetch form subwindow of form */
+</PRE>
+
+Note that curses operations, including <CODE>refresh()</CODE>, on the form,
+should be done on the frame window, not the form subwindow. <P>
+
+It is possible to check from your application whether all of a
+scrollable field is actually displayed within the menu subwindow. Use
+these functions: <P>
+
+<PRE>
+int data_ahead(FORM *form); /* form to be queried */
+
+int data_behind(FORM *form); /* form to be queried */
+</PRE>
+
+The function <CODE>data_ahead()</CODE> returns TRUE if (a) the current
+field is one-line and has undisplayed data off to the right, (b) the current
+field is multi-line and there is data off-screen below it. <P>
+
+The function <CODE>data_behind()</CODE> returns TRUE if the first (upper
+left hand) character position is off-screen (not being displayed). <P>
+
+Finally, there is a function to restore the form window's cursor to the
+value expected by the forms driver: <P>
+
+<PRE>
+int pos_form_cursor(FORM *) /* form to be queried */
+</PRE>
+
+If your application changes the form window cursor, call this function before
+handing control back to the forms driver in order to re-synchronize it. <P>
+
+<H2><A NAME="fdriver">Input Processing in the Forms Driver</A></H2>
+
+The function <CODE>form_driver()</CODE> handles virtualized input requests
+for form navigation, editing, and validation requests, just as
+<CODE>menu_driver</CODE> does for menus (see the section on <A
+HREF="#minput">menu input handling</A>). <P>
+
+<PRE>
+int form_driver(FORM *form, /* form to pass input to */
+ int request); /* form request code */
+</PRE>
+
+Your input virtualization function needs to take input and then convert it
+to either an alphanumeric character (which is treated as data to be
+entered in the currently-selected field), or a forms processing request. <P>
+
+The forms driver provides hooks (through input-validation and
+field-termination functions) with which your application code can check
+that the input taken by the driver matched what was expected. <P>
+
+<H3><A NAME="fpage">Page Navigation Requests</A></H3>
+
+These requests cause page-level moves through the form,
+triggering display of a new form screen. <P>
+
+<DL>
+<DT> <CODE>REQ_NEXT_PAGE</CODE>
+<DD> Move to the next form page.
+<DT> <CODE>REQ_PREV_PAGE</CODE>
+<DD> Move to the previous form page.
+<DT> <CODE>REQ_FIRST_PAGE</CODE>
+<DD> Move to the first form page.
+<DT> <CODE>REQ_LAST_PAGE</CODE>
+<DD> Move to the last form page.
+</DL>
+
+These requests treat the list as cyclic; that is, <CODE>REQ_NEXT_PAGE</CODE>
+from the last page goes to the first, and <CODE>REQ_PREV_PAGE</CODE> from
+the first page goes to the last. <P>
+
+<H3><A NAME="#ffield">Inter-Field Navigation Requests</A></H3>
+
+These requests handle navigation between fields on the same page. <P>
+
+<DL>
+<DT> <CODE>REQ_NEXT_FIELD</CODE>
+<DD> Move to next field.
+<DT> <CODE>REQ_PREV_FIELD</CODE>
+<DD> Move to previous field.
+<DT> <CODE>REQ_FIRST_FIELD</CODE>
+<DD> Move to the first field.
+<DT> <CODE>REQ_LAST_FIELD</CODE>
+<DD> Move to the last field.
+<P>
+<DT> <CODE>REQ_SNEXT_FIELD</CODE>
+<DD> Move to sorted next field.
+<DT> <CODE>REQ_SPREV_FIELD</CODE>
+<DD> Move to sorted previous field.
+<DT> <CODE>REQ_SFIRST_FIELD</CODE>
+<DD> Move to the sorted first field.
+<DT> <CODE>REQ_SLAST_FIELD</CODE>
+<DD> Move to the sorted last field.
+<P>
+<DT> <CODE>REQ_LEFT_FIELD</CODE>
+<DD> Move left to field.
+<DT> <CODE>REQ_RIGHT_FIELD</CODE>
+<DD> Move right to field.
+<DT> <CODE>REQ_UP_FIELD</CODE>
+<DD> Move up to field.
+<DT> <CODE>REQ_DOWN_FIELD</CODE>
+<DD> Move down to field.
+</DL>
+
+These requests treat the list of fields on a page as cyclic; that is,
+<CODE>REQ_NEXT_FIELD</CODE> from the last field goes to the first, and
+<CODE>REQ_PREV_FIELD</CODE> from the first field goes to the last. The
+order of the fields for these (and the <CODE>REQ_FIRST_FIELD</CODE> and
+<CODE>REQ_LAST_FIELD</CODE> requests) is simply the order of the field
+pointers in the form array (as set up by <CODE>new_form()</CODE> or
+<CODE>set_form_fields()</CODE> <P>
+
+It is also possible to traverse the fields as if they had been sorted in
+screen-position order, so the sequence goes left-to-right and top-to-bottom.
+To do this, use the second group of four sorted-movement requests. <P>
+
+Finally, it is possible to move between fields using visual directions up,
+down, right, and left. To accomplish this, use the third group of four
+requests. Note, however, that the position of a form for purposes of these
+requests is its upper-left corner. <P>
+
+For example, suppose you have a multi-line field B, and two
+single-line fields A and C on the same line with B, with A to the left
+of B and C to the right of B. A <CODE>REQ_MOVE_RIGHT</CODE> from A will
+go to B only if A, B, and C <EM>all</EM> share the same first line;
+otherwise it will skip over B to C. <P>
+
+<H3><A NAME="#fifield">Intra-Field Navigation Requests</A></H3>
+
+These requests drive movement of the edit cursor within the currently
+selected field. <P>
+
+<DL>
+<DT> <CODE>REQ_NEXT_CHAR</CODE>
+<DD> Move to next character.
+<DT> <CODE>REQ_PREV_CHAR</CODE>
+<DD> Move to previous character.
+<DT> <CODE>REQ_NEXT_LINE</CODE>
+<DD> Move to next line.
+<DT> <CODE>REQ_PREV_LINE</CODE>
+<DD> Move to previous line.
+<DT> <CODE>REQ_NEXT_WORD</CODE>
+<DD> Move to next word.
+<DT> <CODE>REQ_PREV_WORD</CODE>
+<DD> Move to previous word.
+<DT> <CODE>REQ_BEG_FIELD</CODE>
+<DD> Move to beginning of field.
+<DT> <CODE>REQ_END_FIELD</CODE>
+<DD> Move to end of field.
+<DT> <CODE>REQ_BEG_LINE</CODE>
+<DD> Move to beginning of line.
+<DT> <CODE>REQ_END_LINE</CODE>
+<DD> Move to end of line.
+<DT> <CODE>REQ_LEFT_CHAR</CODE>
+<DD> Move left in field.
+<DT> <CODE>REQ_RIGHT_CHAR</CODE>
+<DD> Move right in field.
+<DT> <CODE>REQ_UP_CHAR</CODE>
+<DD> Move up in field.
+<DT> <CODE>REQ_DOWN_CHAR</CODE>
+<DD> Move down in field.
+</DL>
+
+Each <EM>word</EM> is separated from the previous and next characters
+by whitespace. The commands to move to beginning and end of line or field
+look for the first or last non-pad character in their ranges. <P>
+
+<H3><A NAME="fscroll">Scrolling Requests</A></H3>
+
+Fields that are dynamic and have grown and fields explicitly created
+with offscreen rows are scrollable. One-line fields scroll horizontally;
+multi-line fields scroll vertically. Most scrolling is triggered by
+editing and intra-field movement (the library scrolls the field to keep the
+cursor visible). It is possible to explicitly request scrolling with the
+following requests:
+<P>
+
+<DL>
+<DT> <CODE>REQ_SCR_FLINE</CODE>
+<DD> Scroll vertically forward a line.
+<DT> <CODE>REQ_SCR_BLINE</CODE>
+<DD> Scroll vertically backward a line.
+<DT> <CODE>REQ_SCR_FPAGE</CODE>
+<DD> Scroll vertically forward a page.
+<DT> <CODE>REQ_SCR_BPAGE</CODE>
+<DD> Scroll vertically backward a page.
+<DT> <CODE>REQ_SCR_FHPAGE</CODE>
+<DD> Scroll vertically forward half a page.
+<DT> <CODE>REQ_SCR_BHPAGE</CODE>
+<DD> Scroll vertically backward half a page.
+<DT> <CODE>REQ_SCR_FCHAR</CODE>
+<DD> Scroll horizontally forward a character.
+<DT> <CODE>REQ_SCR_BCHAR</CODE>
+<DD> Scroll horizontally backward a character.
+<DT> <CODE>REQ_SCR_HFLINE</CODE>
+<DD> Scroll horizontally one field width forward.
+<DT> <CODE>REQ_SCR_HBLINE</CODE>
+<DD> Scroll horizontally one field width backward.
+<DT> <CODE>REQ_SCR_HFHALF</CODE>
+<DD> Scroll horizontally one half field width forward.
+<DT> <CODE>REQ_SCR_HBHALF</CODE>
+<DD> Scroll horizontally one half field width backward.
+</DL>
+
+For scrolling purposes, a <EM>page</EM> of a field is the height
+of its visible part. <P>
+
+<H3><A NAME="fedit">Editing Requests</A></H3>
+
+When you pass the forms driver an ASCII character, it is treated as a
+request to add the character to the field's data buffer. Whether this
+is an insertion or a replacement depends on the field's edit mode
+(insertion is the default. <P>
+
+The following requests support editing the field and changing the edit
+mode: <P>
+
+<DL>
+<DT> <CODE>REQ_INS_MODE</CODE>
+<DD> Set insertion mode.
+<DT> <CODE>REQ_OVL_MODE</CODE>
+<DD> Set overlay mode.
+<DT> <CODE>REQ_NEW_LINE</CODE>
+<DD> New line request (see below for explanation).
+<DT> <CODE>REQ_INS_CHAR</CODE>
+<DD> Insert space at character location.
+<DT> <CODE>REQ_INS_LINE</CODE>
+<DD> Insert blank line at character location.
+<DT> <CODE>REQ_DEL_CHAR</CODE>
+<DD> Delete character at cursor.
+<DT> <CODE>REQ_DEL_PREV</CODE>
+<DD> Delete previous word at cursor.
+<DT> <CODE>REQ_DEL_LINE</CODE>
+<DD> Delete line at cursor.
+<DT> <CODE>REQ_DEL_WORD</CODE>
+<DD> Delete word at cursor.
+<DT> <CODE>REQ_CLR_EOL</CODE>
+<DD> Clear to end of line.
+<DT> <CODE>REQ_CLR_EOF</CODE>
+<DD> Clear to end of field.
+<DT> <CODE>REQ_CLEAR_FIELD</CODE>
+<DD> Clear entire field.
+</DL>
+
+The behavior of the <CODE>REQ_NEW_LINE</CODE> and <CODE>REQ_DEL_PREV</CODE> requests
+is complicated and partly controlled by a pair of forms options.
+The special cases are triggered when the cursor is at the beginning of
+a field, or on the last line of the field. <P>
+
+First, we consider <CODE>REQ_NEW_LINE</CODE>: <P>
+
+The normal behavior of <CODE>REQ_NEW_LINE</CODE> in insert mode is to break the
+current line at the position of the edit cursor, inserting the portion of
+the current line after the cursor as a new line following the current
+and moving the cursor to the beginning of that new line (you may think
+of this as inserting a newline in the field buffer). <P>
+
+The normal behavior of <CODE>REQ_NEW_LINE</CODE> in overlay mode is to clear the
+current line from the position of the edit cursor to end of line.
+The cursor is then moved to the beginning of the next line. <P>
+
+However, <CODE>REQ_NEW_LINE</CODE> at the beginning of a field, or on the
+last line of a field, instead does a <CODE>REQ_NEXT_FIELD</CODE>.
+<CODE>O_NL_OVERLOAD</CODE> option is off, this special action is
+disabled. <P>
+
+Now, let us consider <CODE>REQ_DEL_PREV</CODE>: <P>
+
+The normal behavior of <CODE>REQ_DEL_PREV</CODE> is to delete the previous
+character. If insert mode is on, and the cursor is at the start of a
+line, and the text on that line will fit on the previous one, it
+instead appends the contents of the current line to the previous one
+and deletes the current line (you may think of this as deleting a
+newline from the field buffer). <P>
+
+However, <CODE>REQ_DEL_PREV</CODE> at the beginning of a field is instead
+treated as a <CODE>REQ_PREV_FIELD</CODE>. <P> If the
+<CODE>O_BS_OVERLOAD</CODE> option is off, this special action is
+disabled and the forms driver just returns <CODE>E_REQUEST_DENIED</CODE>. <P>
+
+See <A HREF="#frmoptions">Form Options</A> for discussion of how to set
+and clear the overload options. <P>
+
+<H3><A NAME="forder">Order Requests</A></H3>
+
+If the type of your field is ordered, and has associated functions
+for getting the next and previous values of the type from a given value,
+there are requests that can fetch that value into the field buffer: <P>
+
+<DL>
+<DT> <CODE>REQ_NEXT_CHOICE</CODE>
+<DD> Place the successor value of the current value in the buffer.
+<DT> <CODE>REQ_PREV_CHOICE</CODE>
+<DD> Place the predecessor value of the current value in the buffer.
+</DL>
+
+Of the built-in field types, only <CODE>TYPE_ENUM</CODE> has built-in successor
+and predecessor functions. When you define a field type of your own
+(see <A HREF="#fcustom">Custom Validation Types</A>), you can associate
+our own ordering functions. <P>
+
+<H3><A NAME="fappcmds">Application Commands</A></H3>
+
+Form requests are represented as integers above the <CODE>curses</CODE> value
+greater than <CODE>KEY_MAX</CODE> and less than or equal to the constant
+<CODE>MAX_COMMAND</CODE>. If your input-virtualization routine returns a
+value above <CODE>MAX_COMMAND</CODE>, the forms driver will ignore it. <P>
+
+<H2><A NAME="fhooks">Field Change Hooks</A></H2>
+
+It is possible to set function hooks to be executed whenever the
+current field or form changes. Here are the functions that support this: <P>
+
+<PRE>
+typedef void (*HOOK)(); /* pointer to function returning void */
+
+int set_form_init(FORM *form, /* form to alter */
+ HOOK hook); /* initialization hook */
+
+HOOK form_init(FORM *form); /* form to query */
+
+int set_form_term(FORM *form, /* form to alter */
+ HOOK hook); /* termination hook */
+
+HOOK form_term(FORM *form); /* form to query */
+
+int set_field_init(FORM *form, /* form to alter */
+ HOOK hook); /* initialization hook */
+
+HOOK field_init(FORM *form); /* form to query */
+
+int set_field_term(FORM *form, /* form to alter */
+ HOOK hook); /* termination hook */
+
+HOOK field_term(FORM *form); /* form to query */
+</PRE>
+
+These functions allow you to either set or query four different hooks.
+In each of the set functions, the second argument should be the
+address of a hook function. These functions differ only in the timing
+of the hook call. <P>
+
+<DL>
+<DT> form_init
+<DD> This hook is called when the form is posted; also, just after
+each page change operation.
+<DT> field_init
+<DD> This hook is called when the form is posted; also, just after
+each field change
+<DT> field_term
+<DD> This hook is called just after field validation; that is, just before
+the field is altered. It is also called when the form is unposted. <P>
+<DT> form_term
+<DD> This hook is called when the form is unposted; also, just before
+each page change operation.
+</DL>
+
+Calls to these hooks may be triggered
+<OL>
+<LI>When user editing requests are processed by the forms driver
+<LI>When the current page is changed by <CODE>set_current_field()</CODE> call
+<LI>When the current field is changed by a <CODE>set_form_page()</CODE> call
+</OL>
+
+See <A NAME="ffocus">Field Change Commands</A> for discussion of the latter
+two cases. <P>
+
+You can set a default hook for all fields by passing one of the set functions
+a NULL first argument. <P>
+
+You can disable any of these hooks by (re)setting them to NULL, the default
+value. <P>
+
+<H2><A HREF="#ffocus">Field Change Commands</A></H2>
+
+Normally, navigation through the form will be driven by the user's
+input requests. But sometimes it is useful to be able to move the
+focus for editing and viewing under control of your application, or
+ask which field it currently is in. The following functions help you
+accomplish this: <P>
+
+<PRE>
+int set_current_field(FORM *form, /* form to alter */
+ FIELD *field); /* field to shift to */
+
+FIELD *current_field(FORM *form); /* form to query */
+
+int field_index(FORM *form, /* form to query */
+ FIELD *field); /* field to get index of */
+</PRE>
+
+The function <CODE>field_index()</CODE> returns the index of the given field
+in the given form's field array (the array passed to <CODE>new_form()</CODE> or
+<CODE>set_form_fields()</CODE>). <P>
+
+The initial current field of a form is the first active field on the
+first page. The function <CODE>set_form_fields()</CODE> resets this.<P>
+
+It is also possible to move around by pages. <P>
+
+<PRE>
+int set_form_page(FORM *form, /* form to alter */
+ int page); /* page to go to (0-origin) */
+
+int form_page(FORM *form); /* return form's current page */
+</PRE>
+
+The initial page of a newly-created form is 0. The function
+<CODE>set_form_fields()</CODE> resets this. <P>
+
+<H2><A NAME="frmoptions">Form Options</A></H2>
+
+Like fields, forms may have control option bits. They can be changed
+or queried with these functions: <P>
+
+<PRE>
+int set_form_opts(FORM *form, /* form to alter */
+ int attr); /* attribute to set */
+
+int form_opts_on(FORM *form, /* form to alter */
+ int attr); /* attributes to turn on */
+
+int form_opts_off(FORM *form, /* form to alter */
+ int attr); /* attributes to turn off */
+
+int form_opts(FORM *form); /* form to query */
+</PRE>
+
+By default, all options are on. Here are the available option bits:
+
+<DL>
+<DT> O_NL_OVERLOAD
+<DD> Enable overloading of <CODE>REQ_NEW_LINE</CODE> as described in <A
+NAME="fedit">Editing Requests</A>. The value of this option is
+ignored on dynamic fields that have not reached their size limit;
+these have no last line, so the circumstances for triggering a
+<CODE>REQ_NEXT_FIELD</CODE> never arise.
+<DT> O_BS_OVERLOAD
+<DD> Enable overloading of <CODE>REQ_DEL_PREV</CODE> as described in
+<A NAME="fedit">Editing Requests</A>.
+</DL>
+
+The option values are bit-masks and can be composed with logical-or in
+the obvious way. <P>
+
+<H2><A NAME="fcustom">Custom Validation Types</A></H2>
+
+The <CODE>form</CODE> library gives you the capability to define custom
+validation types of your own. Further, the optional additional arguments
+of <CODE>set_field_type</CODE> effectively allow you to parameterize validation
+types. Most of the complications in the validation-type interface have to
+do with the handling of the additional arguments within custom validation
+functions. <P>
+
+<H3><A NAME="flinktypes">Union Types</A></H3>
+
+The simplest way to create a custom data type is to compose it from two
+preexisting ones: <P>
+
+<PRE>
+FIELD *link_fieldtype(FIELDTYPE *type1,
+ FIELDTYPE *type2);
+</PRE>
+
+This function creates a field type that will accept any of the values
+legal for either of its argument field types (which may be either
+predefined or programmer-defined).
+
+If a <CODE>set_field_type()</CODE> call later requires arguments, the new
+composite type expects all arguments for the first type, than all arguments
+for the second. Order functions (see <A HREF="#forder">Order Requests</A>)
+associated with the component types will work on the composite; what it does
+is check the validation function for the first type, then for the second, to
+figure what type the buffer contents should be treated as. <P>
+
+<H3><A NAME="fnewtypes">New Field Types</A></H3>
+
+To create a field type from scratch, you need to specify one or both of the
+following things: <P>
+
+<UL>
+<LI>A character-validation function, to check each character as it is entered.
+<LI>A field-validation function to be applied on exit from the field.
+</UL>
+
+Here's how you do that: <P>
+<PRE>
+typedef int (*HOOK)(); /* pointer to function returning int */
+
+FIELDTYPE *new_fieldtype(HOOK f_validate, /* field validator */
+ HOOK c_validate) /* character validator */
+
+
+int free_fieldtype(FIELDTYPE *ftype); /* type to free */
+</PRE>
+
+At least one of the arguments of <CODE>new_fieldtype()</CODE> must be
+non-NULL. The forms driver will automatically call the new type's
+validation functions at appropriate points in processing a field of
+the new type. <P>
+
+The function <CODE>free_fieldtype()</CODE> deallocates the argument
+fieldtype, freeing all storage associated with it. <P>
+
+Normally, a field validator is called when the user attempts to
+leave the field. Its first argument is a field pointer, from which it
+can get to field buffer 0 and test it. If the function returns TRUE,
+the operation succeeds; if it returns FALSE, the edit cursor stays in
+the field. <P>
+
+A character validator gets the character passed in as a first argument.
+It too should return TRUE if the character is valid, FALSE otherwise. <P>
+
+<H3><A NAME="fcheckargs">Validation Function Arguments</A></H3>
+
+Your field- and character- validation functions will be passed a
+second argument as well. This second argument is the address of a
+structure (which we'll call a <EM>pile</EM>) built from any of the
+field-type-specific arguments passed to <CODE>set_field_type()</CODE>. If
+no such arguments are defined for the field type, this pile pointer
+argument will be NULL. <P>
+
+In order to arrange for such arguments to be passed to your validation
+functions, you must associate a small set of storage-management functions
+with the type. The forms driver will use these to synthesize a pile
+from the trailing arguments of each <CODE>set_field_type()</CODE> argument, and
+a pointer to the pile will be passed to the validation functions. <P>
+
+Here is how you make the association: <P>
+
+<PRE>
+typedef char *(*PTRHOOK)(); /* pointer to function returning (char *) */
+typedef void (*VOIDHOOK)(); /* pointer to function returning void */
+
+int set_fieldtype_arg(FIELDTYPE *type, /* type to alter */
+ PTRHOOK make_str, /* make structure from args */
+ PTRHOOK copy_str, /* make copy of structure */
+ VOIDHOOK free_str); /* free structure storage */
+</PRE>
+
+Here is how the storage-management hooks are used: <P>
+
+<DL>
+<DT> <CODE>make_str</CODE>
+<DD> This function is called by <CODE>set_field_type()</CODE>. It gets one
+argument, a <CODE>va_list</CODE> of the type-specific arguments passed to
+<CODE>set_field_type()</CODE>. It is expected to return a pile pointer to a data
+structure that encapsulates those arguments.
+<DT> <CODE>copy_str</CODE>
+<DD> This function is called by form library functions that allocate new
+field instances. It is expected to take a pile pointer, copy the pile
+to allocated storage, and return the address of the pile copy.
+<DT> <CODE>free_str</CODE>
+<DD> This function is called by field- and type-deallocation routines in the
+library. It takes a pile pointer argument, and is expected to free the
+storage of that pile.
+</DL>
+
+The <CODE>make_str</CODE> and <CODE>copy_str</CODE> functions may return NULL to
+signal allocation failure. The library routines will that call them will
+return error indication when this happens. Thus, your validation functions
+should never see a NULL file pointer and need not check specially for it. <P>
+
+<H3><A NAME="fcustorder">Order Functions For Custom Types</A></H3>
+
+Some custom field types are simply ordered in the same well-defined way
+that <CODE>TYPE_ENUM</CODE> is. For such types, it is possible to define
+successor and predecessor functions to support the <CODE>REQ_NEXT_CHOICE</CODE>
+and <CODE>REQ_PREV_CHOICE</CODE> requests. Here's how: <P>
+
+<PRE>
+typedef int (*INTHOOK)(); /* pointer to function returning int */
+
+int set_fieldtype_arg(FIELDTYPE *type, /* type to alter */
+ INTHOOK succ, /* get successor value */
+ INTHOOK pred); /* get predecessor value */
+</PRE>
+
+The successor and predecessor arguments will each be passed two arguments;
+a field pointer, and a pile pointer (as for the validation functions). They
+are expected to use the function <CODE>field_buffer()</CODE> to read the
+current value, and <CODE>set_field_buffer()</CODE> on buffer 0 to set the next
+or previous value. Either hook may return TRUE to indicate success (a
+legal next or previous value was set) or FALSE to indicate failure. <P>
+
+<H3><A NAME="fcustprobs">Avoiding Problems</A></H3>
+
+The interface for defining custom types is complicated and tricky.
+Rather than attempting to create a custom type entirely from scratch,
+you should start by studying the library source code for whichever of
+the pre-defined types seems to be closest to what you want. <P>
+
+Use that code as a model, and evolve it towards what you really want.
+You will avoid many problems and annoyances that way. The code
+in the <CODE>ncurses</CODE> library has been specifically exempted from
+the package copyright to support this. <P>
+
+If your custom type defines order functions, have do something intuitive
+with a blank field. A useful convention is to make the successor of a
+blank field the types minimum value, and its predecessor the maximum.
+</BODY>
+</HTML>
diff --git a/contrib/ncurses/misc/ncurses.def b/contrib/ncurses/misc/ncurses.def
new file mode 100644
index 000000000000..82170f16ffb8
--- /dev/null
+++ b/contrib/ncurses/misc/ncurses.def
@@ -0,0 +1,442 @@
+LIBRARY ncurses4 INITINSTANCE TERMINSTANCE
+DESCRIPTION "NCurses-4-2-981212, module ncurses"
+CODE LOADONCALL
+DATA LOADONCALL NONSHARED MULTIPLE
+EXPORTS
+ "BC" @662 NONAME
+ "COLORS" @503 NONAME
+ "COLOR_PAIR" @36 NONAME
+ "COLOR_PAIRS" @504 NONAME
+ "COLS" @511 NONAME
+ "ESCDELAY" @513 NONAME
+ "LINES" @510 NONAME
+ "PAIR_NUMBER" @209 NONAME
+ "PC" @660 NONAME
+ "SP" @1003 NONAME
+ "TABSIZE" @512 NONAME
+ "UP" @661 NONAME
+ "_nc_access" @6 NONAME
+ "_nc_ada_getbegyx" @7 NONAME
+ "_nc_ada_getmaxyx" @8 NONAME
+ "_nc_ada_getparyx" @9 NONAME
+ "_nc_ada_getyx" @10 NONAME
+ "_nc_ada_isscroll" @15 NONAME
+ "_nc_ada_mouse_event" @16 NONAME
+ "_nc_ada_mouse_mask" @22 NONAME
+ "_nc_ada_vcheck" @23 NONAME
+ "_nc_add_to_try" @25 NONAME
+ "_nc_background" @27 NONAME
+ "_nc_cap_hash_table" @805 NONAME
+ "_nc_capalias_table" @806 NONAME
+ "_nc_capcmp" @707 NONAME
+ "_nc_captoinfo" @829 NONAME
+ "_nc_comment_end" @819 NONAME
+ "_nc_comment_start" @818 NONAME
+ "_nc_curr_col" @816 NONAME
+ "_nc_curr_file_pos" @817 NONAME
+ "_nc_curr_line" @815 NONAME
+ "_nc_curr_token" @803 NONAME
+ "_nc_do_color" @1037 NONAME
+ "_nc_doalloc" @51 NONAME
+ "_nc_entry_match" @710 NONAME
+ "_nc_err_abort" @826 NONAME
+ "_nc_expand_try" @54 NONAME
+ "_nc_expanded" @58 NONAME
+ "_nc_fallback" @625 NONAME
+ "_nc_find_entry" @809 NONAME
+ "_nc_find_type_entry" @810 NONAME
+ "_nc_first_name" @622 NONAME
+ "_nc_free_entries" @712 NONAME
+ "_nc_freeall" @59 NONAME
+ "_nc_freewin" @60 NONAME
+ "_nc_get_curterm" @63 NONAME
+ "_nc_get_table" @808 NONAME
+ "_nc_get_token" @811 NONAME
+ "_nc_get_type" @823 NONAME
+ "_nc_getenv_num" @65 NONAME
+ "_nc_has_mouse" @67 NONAME
+ "_nc_hash_map" @73 NONAME
+ "_nc_head" @700 NONAME
+ "_nc_home_terminfo" @84 NONAME
+ "_nc_info_hash_table" @804 NONAME
+ "_nc_infoalias_table" @807 NONAME
+ "_nc_infotocap" @830 NONAME
+ "_nc_init_entry" @702 NONAME
+ "_nc_keypad" @1024 NONAME
+ "_nc_lib_traceatr" @91 NONAME
+ "_nc_lib_tracedmp" @92 NONAME
+ "_nc_make_oldhash" @93 NONAME
+ "_nc_makenew" @1025 NONAME
+ "_nc_memmove" @95 NONAME
+ "_nc_merge_entry" @704 NONAME
+ "_nc_msec_cost" @96 NONAME
+ "_nc_mvcur_init" @1014 NONAME
+ "_nc_mvcur_resume" @97 NONAME
+ "_nc_mvcur_wrap" @1015 NONAME
+ "_nc_name_match" @623 NONAME
+ "_nc_nulls_sent" @98 NONAME
+ "_nc_oldnums" @103 NONAME
+ "_nc_outch" @1026 NONAME
+ "_nc_outstr" @1033 NONAME
+ "_nc_panelhook" @106 NONAME
+ "_nc_panic_mode" @814 NONAME
+ "_nc_parse_entry" @706 NONAME
+ "_nc_printf_string" @116 NONAME
+ "_nc_push_token" @812 NONAME
+ "_nc_read_entry" @620 NONAME
+ "_nc_read_entry_source" @709 NONAME
+ "_nc_read_file_entry" @621 NONAME
+ "_nc_read_termcap" @117 NONAME
+ "_nc_remove_key" @118 NONAME
+ "_nc_render" @1027 NONAME
+ "_nc_reset_input" @813 NONAME
+ "_nc_resolve_uses" @711 NONAME
+ "_nc_ripoffline" @119 NONAME
+ "_nc_save_str" @703 NONAME
+ "_nc_screen_chain" @120 NONAME
+ "_nc_screen_init" @127 NONAME
+ "_nc_screen_resume" @129 NONAME
+ "_nc_screen_wrap" @130 NONAME
+ "_nc_scroll_oldhash" @132 NONAME
+ "_nc_scroll_optimize" @1029 NONAME
+ "_nc_scroll_window" @1030 NONAME
+ "_nc_scrolln" @137 NONAME
+ "_nc_set_buffer" @142 NONAME
+ "_nc_set_curterm" @143 NONAME
+ "_nc_set_source" @822 NONAME
+ "_nc_set_type" @824 NONAME
+ "_nc_set_writedir" @144 NONAME
+ "_nc_setupscreen" @1031 NONAME
+ "_nc_sigaction" @145 NONAME
+ "_nc_signal_handler" @1034 NONAME
+ "_nc_slk_format" @146 NONAME
+ "_nc_slk_initialize" @147 NONAME
+ "_nc_start_line" @821 NONAME
+ "_nc_suppress_warnings" @828 NONAME
+ "_nc_synchook" @1035 NONAME
+ "_nc_syntax" @820 NONAME
+ "_nc_syserr_abort" @825 NONAME
+ "_nc_tail" @701 NONAME
+ "_nc_tic_dir" @148 NONAME
+ "_nc_tic_expand" @152 NONAME
+ "_nc_tic_written" @158 NONAME
+ "_nc_timed_wait" @1036 NONAME
+ "_nc_trace_buf" @159 NONAME
+ "_nc_tracebits" @160 NONAME
+ "_nc_tracing" @1010 NONAME
+ "_nc_trans_string" @161 NONAME
+ "_nc_visbuf" @1012 NONAME
+ "_nc_visbuf2" @162 NONAME
+ "_nc_vsscanf" @167 NONAME
+ "_nc_waddch_nosync" @1028 NONAME
+ "_nc_warning" @827 NONAME
+ "_nc_wrap_entry" @705 NONAME
+ "_nc_write_entry" @708 NONAME
+ "_tracechar" @403 NONAME
+ "_tracemouse" @404 NONAME
+ "acs_map" @506 NONAME
+ "addch" @1 NONAME
+ "addchnstr" @2 NONAME
+ "addchstr" @3 NONAME
+ "addnstr" @4 NONAME
+ "addstr" @5 NONAME
+ "attr_get" @14 NONAME
+ "attr_off" @169 NONAME
+ "attr_on" @170 NONAME
+ "attr_set" @17 NONAME
+ "attroff" @11 NONAME
+ "attron" @12 NONAME
+ "attrset" @13 NONAME
+ "baudrate" @18 NONAME
+ "beep" @19 NONAME
+ "bkgd" @20 NONAME
+ "bkgdset" @21 NONAME
+ "boolcodes" @601 NONAME
+ "boolfnames" @602 NONAME
+ "boolnames" @600 NONAME
+ "border" @24 NONAME
+ "box" @26 NONAME
+ "can_change_color" @28 NONAME
+ "cbreak" @29 NONAME
+ "chgat" @30 NONAME
+ "clear" @31 NONAME
+ "clearok" @32 NONAME
+ "clrtobot" @33 NONAME
+ "clrtoeol" @34 NONAME
+ "color_content" @35 NONAME
+ "color_set" @172 NONAME
+ "copywin" @37 NONAME
+ "cur_term" @515 NONAME
+ "curs_set" @38 NONAME
+ "curscr" @501 NONAME
+ "def_prog_mode" @39 NONAME
+ "def_shell_mode" @40 NONAME
+ "define_key" @178 NONAME
+ "del_curterm" @641 NONAME
+ "delay_output" @41 NONAME
+ "delch" @42 NONAME
+ "deleteln" @45 NONAME
+ "delscreen" @43 NONAME
+ "delwin" @44 NONAME
+ "derwin" @46 NONAME
+ "doupdate" @47 NONAME
+ "dupwin" @48 NONAME
+ "echo" @49 NONAME
+ "echochar" @50 NONAME
+ "endwin" @52 NONAME
+ "erasechar" @53 NONAME
+ "filter" @55 NONAME
+ "flash" @56 NONAME
+ "flushinp" @57 NONAME
+ "getbkgd" @183 NONAME
+ "getch" @61 NONAME
+ "getmouse" @356 NONAME
+ "getnstr" @62 NONAME
+ "getstr" @64 NONAME
+ "getwin" @66 NONAME
+ "halfdelay" @68 NONAME
+ "has_colors" @69 NONAME
+ "has_ic" @70 NONAME
+ "has_il" @71 NONAME
+ "has_key" @184 NONAME
+ "hline" @72 NONAME
+ "idcok" @74 NONAME
+ "idlok" @75 NONAME
+ "immedok" @76 NONAME
+ "inch" @77 NONAME
+ "inchnstr" @78 NONAME
+ "inchstr" @79 NONAME
+ "init_acs" @1013 NONAME
+ "init_color" @81 NONAME
+ "init_pair" @82 NONAME
+ "initscr" @80 NONAME
+ "innstr" @83 NONAME
+ "insch" @85 NONAME
+ "insdelln" @86 NONAME
+ "insertln" @87 NONAME
+ "insnstr" @88 NONAME
+ "insstr" @89 NONAME
+ "instr" @90 NONAME
+ "intrflush" @94 NONAME
+ "is_linetouched" @100 NONAME
+ "is_wintouched" @101 NONAME
+ "isendwin" @99 NONAME
+ "key_names" @185 NONAME
+ "keyname" @102 NONAME
+ "keyok" @186 NONAME
+ "keypad" @104 NONAME
+ "killchar" @105 NONAME
+ "leaveok" @107 NONAME
+ "longname" @108 NONAME
+ "mcprint" @187 NONAME
+ "meta" @109 NONAME
+ "mouse_trafo" @188 NONAME
+ "mouseinterval" @360 NONAME
+ "mousemask" @358 NONAME
+ "move" @110 NONAME
+ "mvaddch" @111 NONAME
+ "mvaddchnstr" @112 NONAME
+ "mvaddchstr" @113 NONAME
+ "mvaddnstr" @114 NONAME
+ "mvaddstr" @115 NONAME
+ "mvchgat" @121 NONAME
+ "mvcur" @122 NONAME
+ "mvdelch" @123 NONAME
+ "mvderwin" @124 NONAME
+ "mvgetch" @125 NONAME
+ "mvgetnstr" @126 NONAME
+ "mvgetstr" @128 NONAME
+ "mvhline" @131 NONAME
+ "mvinch" @133 NONAME
+ "mvinchnstr" @134 NONAME
+ "mvinchstr" @135 NONAME
+ "mvinnstr" @136 NONAME
+ "mvinsch" @138 NONAME
+ "mvinsnstr" @139 NONAME
+ "mvinsstr" @140 NONAME
+ "mvinstr" @141 NONAME
+ "mvprintw" @149 NONAME
+ "mvscanw" @150 NONAME
+ "mvvline" @151 NONAME
+ "mvwaddch" @153 NONAME
+ "mvwaddchnstr" @154 NONAME
+ "mvwaddchstr" @155 NONAME
+ "mvwaddnstr" @156 NONAME
+ "mvwaddstr" @157 NONAME
+ "mvwchgat" @163 NONAME
+ "mvwdelch" @164 NONAME
+ "mvwgetch" @165 NONAME
+ "mvwgetnstr" @166 NONAME
+ "mvwgetstr" @168 NONAME
+ "mvwhline" @171 NONAME
+ "mvwin" @173 NONAME
+ "mvwinch" @174 NONAME
+ "mvwinchnstr" @175 NONAME
+ "mvwinchstr" @176 NONAME
+ "mvwinnstr" @177 NONAME
+ "mvwinsch" @179 NONAME
+ "mvwinsnstr" @180 NONAME
+ "mvwinsstr" @181 NONAME
+ "mvwinstr" @182 NONAME
+ "mvwprintw" @190 NONAME
+ "mvwscanw" @191 NONAME
+ "mvwvline" @192 NONAME
+ "napms" @194 NONAME
+ "newpad" @195 NONAME
+ "newscr" @502 NONAME
+ "newterm" @196 NONAME
+ "newwin" @197 NONAME
+ "nl" @198 NONAME
+ "nocbreak" @199 NONAME
+ "nodelay" @200 NONAME
+ "noecho" @201 NONAME
+ "nonl" @202 NONAME
+ "noqiflush" @203 NONAME
+ "noraw" @204 NONAME
+ "notimeout" @205 NONAME
+ "numcodes" @604 NONAME
+ "numfnames" @605 NONAME
+ "numnames" @603 NONAME
+ "ospeed" @663 NONAME
+ "overlay" @206 NONAME
+ "overwrite" @207 NONAME
+ "pair_content" @208 NONAME
+ "pechochar" @210 NONAME
+ "pnoutrefresh" @212 NONAME
+ "prefresh" @213 NONAME
+ "printw" @214 NONAME
+ "putp" @215 NONAME
+ "putwin" @216 NONAME
+ "qiflush" @217 NONAME
+ "raw" @218 NONAME
+ "redrawwin" @219 NONAME
+ "refresh" @220 NONAME
+ "reset_prog_mode" @222 NONAME
+ "reset_shell_mode" @223 NONAME
+ "resetty" @221 NONAME
+ "resizeterm" @189 NONAME
+ "restartterm" @643 NONAME
+ "ripoffline" @224 NONAME
+ "savetty" @225 NONAME
+ "scanw" @226 NONAME
+ "scr_dump" @227 NONAME
+ "scr_init" @228 NONAME
+ "scr_restore" @232 NONAME
+ "scr_set" @233 NONAME
+ "scrl" @229 NONAME
+ "scroll" @230 NONAME
+ "scrollok" @231 NONAME
+ "set_curterm" @640 NONAME
+ "set_term" @236 NONAME
+ "setscrreg" @235 NONAME
+ "setupterm" @644 NONAME
+ "slk_attr" @193 NONAME
+ "slk_attr_set" @211 NONAME
+ "slk_attroff" @237 NONAME
+ "slk_attron" @239 NONAME
+ "slk_attrset" @241 NONAME
+ "slk_clear" @243 NONAME
+ "slk_color" @234 NONAME
+ "slk_init" @244 NONAME
+ "slk_label" @245 NONAME
+ "slk_noutrefresh" @246 NONAME
+ "slk_refresh" @247 NONAME
+ "slk_restore" @248 NONAME
+ "slk_set" @249 NONAME
+ "slk_touch" @250 NONAME
+ "standend" @253 NONAME
+ "standout" @252 NONAME
+ "start_color" @254 NONAME
+ "stdscr" @500 NONAME
+ "strcodes" @608 NONAME
+ "strfnames" @609 NONAME
+ "strnames" @606 NONAME
+ "subpad" @255 NONAME
+ "subwin" @256 NONAME
+ "syncok" @257 NONAME
+ "termattrs" @258 NONAME
+ "termname" @259 NONAME
+ "tgetent" @645 NONAME
+ "tgetflag" @646 NONAME
+ "tgetnum" @647 NONAME
+ "tgetstr" @648 NONAME
+ "tgoto" @649 NONAME
+ "tigetflag" @260 NONAME
+ "tigetnum" @261 NONAME
+ "tigetstr" @262 NONAME
+ "timeout" @238 NONAME
+ "tparm" @653 NONAME
+ "tputs" @655 NONAME
+ "trace" @405 NONAME
+ "ttytype" @514 NONAME
+ "typeahead" @264 NONAME
+ "unctrl" @361 NONAME
+ "ungetch" @265 NONAME
+ "ungetmouse" @357 NONAME
+ "untouchwin" @267 NONAME
+ "use_default_colors" @240 NONAME
+ "use_env" @268 NONAME
+ "vidattr" @269 NONAME
+ "vidputs" @271 NONAME
+ "vline" @273 NONAME
+ "vw_printw" @242 NONAME
+ "vw_scanw" @251 NONAME
+ "vwprintw" @275 NONAME
+ "vwscanw" @277 NONAME
+ "waddch" @279 NONAME
+ "waddchnstr" @280 NONAME
+ "waddchstr" @281 NONAME
+ "waddnstr" @282 NONAME
+ "waddstr" @283 NONAME
+ "wattr_get" @291 NONAME
+ "wattr_off" @293 NONAME
+ "wattr_on" @292 NONAME
+ "wattr_set" @263 NONAME
+ "wattroff" @289 NONAME
+ "wattron" @288 NONAME
+ "wattrset" @290 NONAME
+ "wbkgd" @295 NONAME
+ "wbkgdset" @296 NONAME
+ "wborder" @299 NONAME
+ "wchgat" @301 NONAME
+ "wclear" @302 NONAME
+ "wclrtobot" @303 NONAME
+ "wclrtoeol" @304 NONAME
+ "wcolor_set" @266 NONAME
+ "wcursyncup" @305 NONAME
+ "wdelch" @306 NONAME
+ "wdeleteln" @307 NONAME
+ "wechochar" @308 NONAME
+ "wenclose" @359 NONAME
+ "werase" @310 NONAME
+ "wgetch" @312 NONAME
+ "wgetnstr" @313 NONAME
+ "wgetstr" @315 NONAME
+ "whline" @318 NONAME
+ "winch" @320 NONAME
+ "winchnstr" @321 NONAME
+ "winchstr" @322 NONAME
+ "winnstr" @323 NONAME
+ "winsch" @325 NONAME
+ "winsdelln" @326 NONAME
+ "winsertln" @327 NONAME
+ "winsnstr" @328 NONAME
+ "winsstr" @329 NONAME
+ "winstr" @330 NONAME
+ "wmouse_trafo" @270 NONAME
+ "wmove" @338 NONAME
+ "wnoutrefresh" @339 NONAME
+ "wprintw" @340 NONAME
+ "wredrawln" @341 NONAME
+ "wrefresh" @342 NONAME
+ "wresize" @343 NONAME
+ "wscanw" @344 NONAME
+ "wscrl" @345 NONAME
+ "wsetscrreg" @346 NONAME
+ "wstandend" @348 NONAME
+ "wstandout" @347 NONAME
+ "wsyncdown" @349 NONAME
+ "wsyncup" @350 NONAME
+ "wtimeout" @351 NONAME
+ "wtouchln" @352 NONAME
+ "wvline" @354 NONAME
diff --git a/contrib/ncurses/misc/ncurses.ref b/contrib/ncurses/misc/ncurses.ref
new file mode 100644
index 000000000000..cf4de7d59243
--- /dev/null
+++ b/contrib/ncurses/misc/ncurses.ref
@@ -0,0 +1,572 @@
+LIBRARY ncurses2 INITINSTANCE
+DESCRIPTION 'NCurses 1.9.9e-1 for OS/2 - base library'
+EXPORTS
+;************
+;* curses.h *
+;************
+
+ "stdscr" @500 NONAME ; variable
+ "curscr" @501 NONAME ; variable
+ "newscr" @502 NONAME ; variable
+ "COLORS" @503 NONAME ; variable
+ "COLOR_PAIRS" @504 NONAME ; variable
+ "color_pairs" @505 NONAME ; variable
+ "acs_map" @506 NONAME ; variable
+ "LINES" @510 NONAME ; variable
+ "COLS" @511 NONAME ; variable
+ "TABSIZE" @512 NONAME ; variable
+ "ESCDELAY" @513 NONAME ; variable
+ "ttytype" @514 NONAME ; variable
+ "cur_term" @515 NONAME ; variable
+
+ "addch" @1 NONAME ; generated
+ "addchnstr" @2 NONAME ; generated
+ "addchstr" @3 NONAME ; generated
+ "addnstr" @4 NONAME ; generated
+ "addstr" @5 NONAME ; generated
+; "addnwstr" @6 NONAME ; missing
+; "addwstr" @7 NONAME ; missing
+; "add_wch" @8 NONAME ; missing
+; "add_wchnstr" @9 NONAME ; missing
+; "add_wchstr" @10 NONAME ; missing
+ "attroff" @11 NONAME ; generated
+ "attron" @12 NONAME ; generated
+ "attrset" @13 NONAME ; generated
+ "attr_get" @14 NONAME ; generated
+; "attr_off" @15 NONAME ; implemented << NO!!
+; "attr_on" @16 NONAME ; implemented << NO!!
+ "attr_set" @17 NONAME ; generated
+ "baudrate" @18 NONAME ; implemented
+ "beep" @19 NONAME ; implemented
+ "bkgd" @20 NONAME ; generated
+ "bkgdset" @21 NONAME ; generated
+; "bkgrndset" @22 NONAME ; missing
+; "bkgrnd" @23 NONAME ; missing
+ "border" @24 NONAME ; generated
+; "border_set" @25 NONAME ; missing
+ "box" @26 NONAME ; generated
+; "box_set" @27 NONAME ; missing
+ "can_change_color" @28 NONAME ; implemented
+ "cbreak" @29 NONAME ; implemented
+ "chgat" @30 NONAME ; generated
+ "clear" @31 NONAME ; generated
+ "clearok" @32 NONAME ; implemented
+ "clrtobot" @33 NONAME ; generated
+ "clrtoeol" @34 NONAME ; generated
+ "color_content" @35 NONAME ; implemented
+ "COLOR_PAIR" @36 NONAME ; generated
+ "copywin" @37 NONAME ; implemented
+ "curs_set" @38 NONAME ; implemented
+ "def_prog_mode" @39 NONAME ; implemented
+ "def_shell_mode" @40 NONAME ; implemented
+ "delay_output" @41 NONAME ; implemented
+ "delch" @42 NONAME ; generated
+ "delscreen" @43 NONAME ; implemented
+ "delwin" @44 NONAME ; implemented
+ "deleteln" @45 NONAME ; generated
+ "derwin" @46 NONAME ; implemented
+ "doupdate" @47 NONAME ; implemented
+ "dupwin" @48 NONAME ; implemented
+ "echo" @49 NONAME ; implemented
+ "echochar" @50 NONAME ; generated
+; "echo_wchar" @51 NONAME ; missing
+ "endwin" @52 NONAME ; implemented
+ "erasechar" @53 NONAME ; implemented
+; "erase_wchar" @54 NONAME ; missing
+ "filter" @55 NONAME ; implemented
+ "flash" @56 NONAME ; implemented
+ "flushinp" @57 NONAME ; implemented
+; "getbkgd" @58 NONAME ; missing
+; "getbkgrnd" @59 NONAME ; missing
+; "getcchar" @60 NONAME ; missing
+ "getch" @61 NONAME ; generated
+ "getnstr" @62 NONAME ; generated
+; "getn_wstr" @63 NONAME ; missing
+ "getstr" @64 NONAME ; generated
+; "get_wch" @65 NONAME ; missing
+ "getwin" @66 NONAME ; not in XPG4
+; "get_wstr" @67 NONAME ; missing
+ "halfdelay" @68 NONAME ; implemented
+ "has_colors" @69 NONAME ; implemented
+ "has_ic" @70 NONAME ; implemented
+ "has_il" @71 NONAME ; implemented
+ "hline" @72 NONAME ; generated
+; "hline_set" @73 NONAME ; missing
+ "idcok" @74 NONAME ; implemented
+ "idlok" @75 NONAME ; implemented
+ "immedok" @76 NONAME ; implemented
+ "inch" @77 NONAME ; generated
+ "inchnstr" @78 NONAME ; generated
+ "inchstr" @79 NONAME ; generated
+ "initscr" @80 NONAME ; implemented
+ "init_color" @81 NONAME ; implemented
+ "init_pair" @82 NONAME ; implemented
+ "innstr" @83 NONAME ; generated
+; "innwstr" @84 NONAME ; missing
+ "insch" @85 NONAME ; generated
+ "insdelln" @86 NONAME ; generated
+ "insertln" @87 NONAME ; generated
+ "insnstr" @88 NONAME ; generated
+ "insstr" @89 NONAME ; generated
+ "instr" @90 NONAME ; generated
+; "ins_nwstr" @91 NONAME ; missing
+; "ins_wch" @92 NONAME ; missing
+; "ins_wstr" @93 NONAME ; missing
+ "intrflush" @94 NONAME ; implemented
+; "inwstr" @95 NONAME ; missing
+; "in_wch" @96 NONAME ; missing
+; "in_wchstr" @97 NONAME ; missing
+; "in_wchntr" @98 NONAME ; missing
+ "isendwin" @99 NONAME ; implemented
+ "is_linetouched" @100 NONAME ; implemented
+ "is_wintouched" @101 NONAME ; implemented
+ "keyname" @102 NONAME ; implemented
+; "key_name" @103 NONAME ; missing
+ "keypad" @104 NONAME ; implemented
+ "killchar" @105 NONAME ; implemented
+; "killwchar" @106 NONAME ; missing
+ "leaveok" @107 NONAME ; implemented
+ "longname" @108 NONAME ; implemented
+ "meta" @109 NONAME ; implemented
+ "move" @110 NONAME ; generated
+ "mvaddch" @111 NONAME ; generated
+ "mvaddchnstr" @112 NONAME ; generated
+ "mvaddchstr" @113 NONAME ; generated
+ "mvaddnstr" @114 NONAME ; generated
+ "mvaddstr" @115 NONAME ; generated
+; "mvaddnwstr" @116 NONAME ; missing
+; "mvaddwstr" @117 NONAME ; missing
+; "mvadd_wch" @118 NONAME ; missing
+; "mvadd_wchnstr" @119 NONAME ; missing
+; "mvadd_wchstr" @120 NONAME ; missing
+ "mvchgat" @121 NONAME ; generated
+ "mvcur" @122 NONAME ; implemented
+ "mvdelch" @123 NONAME ; generated
+ "mvderwin" @124 NONAME ; implemented
+ "mvgetch" @125 NONAME ; generated
+ "mvgetnstr" @126 NONAME ; generated
+; "mvgetn_wstr" @127 NONAME ; missing
+ "mvgetstr" @128 NONAME ; generated
+; "mvget_wch" @129 NONAME ; missing
+; "mvget_wstr" @130 NONAME ; missing
+ "mvhline" @131 NONAME ; generated
+; "mvhline_set" @132 NONAME ; missing
+ "mvinch" @133 NONAME ; generated
+ "mvinchnstr" @134 NONAME ; generated
+ "mvinchstr" @135 NONAME ; generated
+ "mvinnstr" @136 NONAME ; generated
+; "mvinnwstr" @137 NONAME ; missing
+ "mvinsch" @138 NONAME ; generated
+ "mvinsnstr" @139 NONAME ; generated
+ "mvinsstr" @140 NONAME ; generated
+ "mvinstr" @141 NONAME ; generated
+; "mvins_nwstr" @142 NONAME ; missing
+; "mvins_wch" @143 NONAME ; missing
+; "mvins_wstr" @144 NONAME ; missing
+; "mvinwstr" @145 NONAME ; missing
+; "mvin_wch" @146 NONAME ; missing
+; "mvin_wchstr" @147 NONAME ; missing
+; "mvin_wchntr" @148 NONAME ; missing
+ "mvprintw" @149 NONAME ; implemented
+ "mvscanw" @150 NONAME ; implemented
+ "mvvline" @151 NONAME ; generated
+; "mvvline_set" @152 NONAME ; missing
+ "mvwaddch" @153 NONAME ; generated
+ "mvwaddchnstr" @154 NONAME ; generated
+ "mvwaddchstr" @155 NONAME ; generated
+ "mvwaddnstr" @156 NONAME ; generated
+ "mvwaddstr" @157 NONAME ; generated
+; "mvwaddnwstr" @158 NONAME ; missing
+; "mvwaddwstr" @159 NONAME ; missing
+; "mvwadd_wch" @160 NONAME ; missing
+; "mvwadd_wchnstr" @161 NONAME ; missing
+; "mvwadd_wchstr" @162 NONAME ; missing
+ "mvwchgat" @163 NONAME ; generated
+ "mvwdelch" @164 NONAME ; generated
+ "mvwgetch" @165 NONAME ; generated
+ "mvwgetnstr" @166 NONAME ; generated
+; "mvwgetn_wstr" @167 NONAME ; missing
+ "mvwgetstr" @168 NONAME ; generated
+; "mvwget_wch" @169 NONAME ; missing
+; "mvwget_wstr" @170 NONAME ; missing
+ "mvwhline" @171 NONAME ; generated
+; "mvwhline_set" @172 NONAME ; missing
+ "mvwin" @173 NONAME ; implemented
+ "mvwinch" @174 NONAME ; generated
+ "mvwinchnstr" @175 NONAME ; generated
+ "mvwinchstr" @176 NONAME ; generated
+ "mvwinnstr" @177 NONAME ; generated
+; "mvwinnwstr" @178 NONAME ; missing
+ "mvwinsch" @179 NONAME ; generated
+ "mvwinsnstr" @180 NONAME ; generated
+ "mvwinsstr" @181 NONAME ; generated
+ "mvwinstr" @182 NONAME ; generated
+; "mvwins_nwstr" @183 NONAME ; missing
+; "mvwins_wch" @184 NONAME ; missing
+; "mvwins_wstr" @185 NONAME ; missing
+; "mvwinwstr" @186 NONAME ; missing
+; "mvwin_wch" @187 NONAME ; missing
+; "mvwin_wchnstr" @188 NONAME ; missing
+; "mvwin_wchstr" @189 NONAME ; missing
+ "mvwprintw" @190 NONAME ; implemented
+ "mvwscanw" @191 NONAME ; implemented
+ "mvwvline" @192 NONAME ; generated
+; "mvwvline_set" @193 NONAME ; missing
+ "napms" @194 NONAME ; implemented
+ "newpad" @195 NONAME ; implemented
+ "newterm" @196 NONAME ; implemented
+ "newwin" @197 NONAME ; implemented
+ "nl" @198 NONAME ; implemented
+ "nocbreak" @199 NONAME ; implemented
+ "nodelay" @200 NONAME ; implemented
+ "noecho" @201 NONAME ; implemented
+ "nonl" @202 NONAME ; implemented
+ "noqiflush" @203 NONAME ; implemented
+ "noraw" @204 NONAME ; implemented
+ "notimeout" @205 NONAME ; implemented
+ "overlay" @206 NONAME ; implemented
+ "overwrite" @207 NONAME ; implemented
+ "pair_content" @208 NONAME ; implemented
+ "PAIR_NUMBER" @209 NONAME ; generated
+ "pechochar" @210 NONAME ; implemented
+; "pecho_wchar" @211 NONAME ; missing
+ "pnoutrefresh" @212 NONAME ; implemented
+ "prefresh" @213 NONAME ; implemented
+ "printw" @214 NONAME ; implemented
+ "putp" @215 NONAME ; implemented
+ "putwin" @216 NONAME ; implemented
+ "qiflush" @217 NONAME ; implemented
+ "raw" @218 NONAME ; implemented
+ "redrawwin" @219 NONAME ; generated
+ "refresh" @220 NONAME ; generated
+ "resetty" @221 NONAME ; implemented
+ "reset_prog_mode" @222 NONAME ; implemented
+ "reset_shell_mode" @223 NONAME ; implemented
+ "ripoffline" @224 NONAME ; implemented
+ "savetty" @225 NONAME ; implemented
+ "scanw" @226 NONAME ; implemented
+ "scr_dump" @227 NONAME ; implemented
+ "scr_init" @228 NONAME ; implemented
+ "scrl" @229 NONAME ; generated
+ "scroll" @230 NONAME ; generated
+ "scrollok" @231 NONAME ; implemented
+ "scr_restore" @232 NONAME ; implemented
+ "scr_set" @233 NONAME ; implemented
+; "setcchar" @234 NONAME ; missing
+ "setscrreg" @235 NONAME ; generated
+ "set_term" @236 NONAME ; implemented
+ "slk_attroff" @237 NONAME ; implemented
+; "slk_attr_off" @238 NONAME ; missing
+ "slk_attron" @239 NONAME ; implemented
+; "slk_attr_on" @240 NONAME ; missing
+ "slk_attrset" @241 NONAME ; implemented
+; "slk_attr_set" @242 NONAME ; missing
+ "slk_clear" @243 NONAME ; implemented
+ "slk_init" @244 NONAME ; implemented
+ "slk_label" @245 NONAME ; implemented
+ "slk_noutrefresh" @246 NONAME ; implemented
+ "slk_refresh" @247 NONAME ; implemented
+ "slk_restore" @248 NONAME ; implemented
+ "slk_set" @249 NONAME ; implemented
+ "slk_touch" @250 NONAME ; implemented
+; "slk_wset" @251 NONAME ; missing
+ "standout" @252 NONAME ; generated
+ "standend" @253 NONAME ; generated
+ "start_color" @254 NONAME ; implemented
+ "subpad" @255 NONAME ; implemented
+ "subwin" @256 NONAME ; implemented
+ "syncok" @257 NONAME ; implemented
+ "termattrs" @258 NONAME ; implemented
+ "termname" @259 NONAME ; implemented
+ "tigetflag" @260 NONAME ; implemented
+ "tigetnum" @261 NONAME ; implemented
+ "tigetstr" @262 NONAME ; implemented
+; "timeout" @263 NONAME ; implemented << NO!!
+ "typeahead" @264 NONAME ; implemented
+ "ungetch" @265 NONAME ; implemented
+; "unget_wch" @266 NONAME ; missing
+ "untouchwin" @267 NONAME ; generated
+ "use_env" @268 NONAME ; implemented
+ "vidattr" @269 NONAME ; implemented
+; "vid_attr" @270 NONAME ; missing
+ "vidputs" @271 NONAME ; implemented
+; "vid_puts" @272 NONAME ; missing
+ "vline" @273 NONAME ; generated
+; "vline_set" @274 NONAME ; missing
+ "vwprintw" @275 NONAME ; implemented
+; "vw_printw" @276 NONAME ; implemented << NO!!
+ "vwscanw" @277 NONAME ; implemented
+; "vw_scanw" @278 NONAME ; implemented << NO!!
+ "waddch" @279 NONAME ; implemented
+ "waddchnstr" @280 NONAME ; implemented
+ "waddchstr" @281 NONAME ; generated
+ "waddnstr" @282 NONAME ; implemented
+ "waddstr" @283 NONAME ; generated
+; "waddwstr" @284 NONAME ; missing
+; "wadd_wch" @285 NONAME ; missing
+; "wadd_wchnstr" @286 NONAME ; missing
+; "wadd_wchstr" @287 NONAME ; missing
+ "wattron" @288 NONAME ; generated
+ "wattroff" @289 NONAME ; generated
+ "wattrset" @290 NONAME ; generated
+ "wattr_get" @291 NONAME ; generated
+ "wattr_on" @292 NONAME ; implemented
+ "wattr_off" @293 NONAME ; implemented
+; "wattr_set" @294 NONAME ; implemented << NO!!
+ "wbkgd" @295 NONAME ; implemented
+ "wbkgdset" @296 NONAME ; generated
+; "wbkgrndset" @297 NONAME ; missing
+; "wbkgrnd" @298 NONAME ; missing
+ "wborder" @299 NONAME ; implemented
+; "wborder_set" @300 NONAME ; missing
+ "wchgat" @301 NONAME ; implemented
+ "wclear" @302 NONAME ; implemented
+ "wclrtobot" @303 NONAME ; implemented
+ "wclrtoeol" @304 NONAME ; implemented
+ "wcursyncup" @305 NONAME ; implemented
+ "wdelch" @306 NONAME ; implemented
+ "wdeleteln" @307 NONAME ; generated
+ "wechochar" @308 NONAME ; implemented
+; "wecho_wchar" @309 NONAME ; missing
+ "werase" @310 NONAME ; implemented
+; "wgetbkgrnd" @311 NONAME ; missing
+ "wgetch" @312 NONAME ; implemented
+ "wgetnstr" @313 NONAME ; implemented
+; "wgetn_wstr" @314 NONAME ; missing
+ "wgetstr" @315 NONAME ; generated
+; "wget_wch" @316 NONAME ; missing
+; "wget_wstr" @317 NONAME ; missing
+ "whline" @318 NONAME ; implemented
+; "whline_set" @319 NONAME ; missing
+ "winch" @320 NONAME ; generated
+ "winchnstr" @321 NONAME ; implemented
+ "winchstr" @322 NONAME ; generated
+ "winnstr" @323 NONAME ; implemented
+; "winnwstr" @324 NONAME ; missing
+ "winsch" @325 NONAME ; implemented
+ "winsdelln" @326 NONAME ; implemented
+ "winsertln" @327 NONAME ; generated
+ "winsnstr" @328 NONAME ; implemented
+ "winsstr" @329 NONAME ; generated
+ "winstr" @330 NONAME ; generated
+; "wins_nwstr" @331 NONAME ; missing
+; "wins_wch" @332 NONAME ; missing
+; "wins_wstr" @333 NONAME ; missing
+; "winwstr" @334 NONAME ; missing
+; "win_wch" @335 NONAME ; missing
+; "win_wchnstr" @336 NONAME ; missing
+; "win_wchstr" @337 NONAME ; missing
+ "wmove" @338 NONAME ; implemented
+ "wnoutrefresh" @339 NONAME ; implemented
+ "wprintw" @340 NONAME ; implemented
+ "wredrawln" @341 NONAME ; implemented
+ "wrefresh" @342 NONAME ; implemented
+ "wresize" @343 NONAME ; implemented
+ "wscanw" @344 NONAME ; implemented
+ "wscrl" @345 NONAME ; implemented
+ "wsetscrreg" @346 NONAME ; implemented
+ "wstandout" @347 NONAME ; generated
+ "wstandend" @348 NONAME ; generated
+ "wsyncdown" @349 NONAME ; implemented
+ "wsyncup" @350 NONAME ; implemented
+ "wtimeout" @351 NONAME ; implemented
+ "wtouchln" @352 NONAME ; implemented
+; "wunctrl" @353 NONAME ; missing
+ "wvline" @354 NONAME ; implemented
+; "wvline_set" @355 NONAME ; missing
+
+ "getmouse" @356 NONAME
+ "ungetmouse" @357 NONAME
+ "mousemask" @358 NONAME
+ "wenclose" @359 NONAME
+ "mouseinterval" @360 NONAME
+
+; from unctrl.h
+ "unctrl" @361 NONAME
+
+; publics for tracing
+ "_tracef" @400 NONAME
+ "_tracedump" @401 NONAME
+ "_traceattr" @402 NONAME
+ "_tracechar" @403 NONAME
+ "_tracemouse" @404 NONAME
+ "trace" @405 NONAME
+
+;**********
+;* term.h *
+;**********
+ "boolnames" @600 NONAME ; variable
+ "boolcodes" @601 NONAME ; variable
+ "boolfnames" @602 NONAME ; variable
+ "numnames" @603 NONAME ; variable
+ "numcodes" @604 NONAME ; variable
+ "numfnames" @605 NONAME ; variable
+ "strnames" @606 NONAME ; variable
+ "strcodes" @608 NONAME ; variable
+ "strfnames" @609 NONAME ; variable
+
+; internals
+ "_nc_read_entry" @620 NONAME
+ "_nc_read_file_entry" @621 NONAME
+ "_nc_first_name" @622 NONAME
+ "_nc_name_match" @623 NONAME
+ "_nc_read_termcap_entry" @624 NONAME
+ "_nc_fallback" @625 NONAME
+
+; entry points
+ "set_curterm" @640 NONAME
+ "del_curterm" @641 NONAME
+
+; entry points
+; "putp" @642 NONAME ; already defined
+ "restartterm" @643 NONAME
+ "setupterm" @644 NONAME
+ "tgetent" @645 NONAME
+ "tgetflag" @646 NONAME
+ "tgetnum" @647 NONAME
+ "tgetstr" @648 NONAME
+ "tgoto" @649 NONAME
+; "tigetflag" @650 NONAME ; already defined
+; "tigetnum" @651 NONAME ; already defined
+; "tigetstr" @652 NONAME ; already defined
+ "tparm" @653 NONAME
+ "tparam" @654 NONAME
+ "tputs" @655 NONAME
+
+;*************
+;* termcap.h *
+;*************
+; the functions are already defined in term.h
+ "PC" @660 NONAME
+ "UP" @661 NONAME
+ "BC" @662 NONAME
+ "ospeed" @663 NONAME
+
+;****************
+;* term_entry.h *
+;****************
+ "_nc_head" @700 NONAME
+ "_nc_tail" @701 NONAME
+
+; alloc_entry.c: elementary allocation code
+ "_nc_init_entry" @702 NONAME
+ "_nc_save_str" @703 NONAME
+ "_nc_merge_entry" @704 NONAME
+ "_nc_wrap_entry" @705 NONAME
+
+; parse_entry.c: entry-parsing code
+ "_nc_parse_entry" @706 NONAME
+ "_nc_capcmp" @707 NONAME
+
+; write_entry.c: writing an entry to the file system
+ "_nc_write_entry" @708 NONAME
+
+; comp_parse.c: entry list handling
+ "_nc_read_entry_source" @709 NONAME
+ "_nc_entry_match" @710 NONAME
+ "_nc_resolve_uses" @711 NONAME
+ "_nc_free_entries" @712 NONAME
+
+;*********
+;* tic.h *
+;*********
+; "_nc_tracing" @800 NONAME ; defined below
+; "_nc_tracef" @801 NONAME ; missing
+; "_nc_visbuf" @802 NONAME ; defined below
+
+ "_nc_curr_token" @803 NONAME
+
+ "_nc_info_hash_table" @804 NONAME
+ "_nc_cap_hash_table" @805 NONAME
+
+ "_nc_capalias_table" @806 NONAME
+ "_nc_infoalias_table" @807 NONAME
+ "_nc_get_table" @808 NONAME
+
+; comp_hash.c: name lookup
+ "_nc_find_entry" @809 NONAME
+ "_nc_find_type_entry" @810 NONAME
+
+; comp_scan.c: lexical analysis
+ "_nc_get_token" @811 NONAME
+ "_nc_push_token" @812 NONAME
+ "_nc_reset_input" @813 NONAME
+ "_nc_panic_mode" @814 NONAME
+ "_nc_curr_line" @815 NONAME
+ "_nc_curr_col" @816 NONAME
+ "_nc_curr_file_pos" @817 NONAME
+ "_nc_comment_start" @818 NONAME
+ "_nc_comment_end" @819 NONAME
+ "_nc_syntax" @820 NONAME
+ "_nc_start_line" @821 NONAME
+
+; comp_error.c: warning & abort messages
+ "_nc_set_source" @822 NONAME
+ "_nc_get_type" @823 NONAME
+ "_nc_set_type" @824 NONAME
+ "_nc_syserr_abort" @825 NONAME
+ "_nc_err_abort" @826 NONAME
+ "_nc_warning" @827 NONAME
+ "_nc_suppress_warnings" @828 NONAME
+
+; captoinfo.c: capability conversion
+ "_nc_captoinfo" @829 NONAME
+ "_nc_infotocap" @830 NONAME
+
+; comp_main.c: compiler main
+; "_nc_progname" @831 NONAME ; no need to export it
+
+
+; *****************
+; NCurses internals -- just for progs/*.exe and the library itself.
+; *****************
+
+; For broken linkers
+; "_nc_screen" @1000 NONAME
+; "_nc_alloc_screen" @1001 NONAME
+; "_nc_set_screen" @1002 NONAME
+
+; For not so broken linkers
+ "SP" @1003 NONAME
+
+; Who knows what this is for
+ "_slk_init" @1004 NONAME
+ "slk_initialize" @1005 NONAME
+
+; Tracing -- all functions used internally
+ "_nc_tracing" @1010 NONAME
+ "_nc_tputs_trace" @1011 NONAME
+ "_nc_visbuf" @1012 NONAME
+
+; lib_acs.c
+ "init_acs" @1013 NONAME
+
+; lib_mvcur.c
+ "_nc_mvcur_init" @1014 NONAME
+ "_nc_mvcur_wrap" @1015 NONAME
+ "_nc_mvcur_scrolln" @1016 NONAME
+
+; lib_mouse.c
+ "_nc_mouse_init" @1017 NONAME
+ "_nc_mouse_event" @1018 NONAME
+ "_nc_mouse_inline" @1019 NONAME
+ "_nc_mouse_parse" @1020 NONAME
+ "_nc_mouse_wrap" @1021 NONAME
+ "_nc_mouse_resume" @1022 NONAME
+ "_nc_max_click_interval" @1023 NONAME
+
+; elsewhere ...
+ "_nc_keypad" @1024 NONAME
+ "_nc_makenew" @1025 NONAME
+ "_nc_outch" @1026 NONAME
+ "_nc_render" @1027 NONAME
+ "_nc_waddch_nosync" @1028 NONAME
+ "_nc_scroll_optimize" @1029 NONAME
+ "_nc_scroll_window" @1030 NONAME
+ "_nc_setupscreen" @1031 NONAME
+ "_nc_backspace" @1032 NONAME
+ "_nc_outstr" @1033 NONAME
+ "_nc_signal_handler" @1034 NONAME
+ "_nc_synchook" @1035 NONAME
+ "_nc_timed_wait" @1036 NONAME
+ "_nc_do_color" @1037 NONAME
diff --git a/contrib/ncurses/misc/panel.def b/contrib/ncurses/misc/panel.def
new file mode 100644
index 000000000000..868813c4f102
--- /dev/null
+++ b/contrib/ncurses/misc/panel.def
@@ -0,0 +1,25 @@
+LIBRARY panel4 INITINSTANCE TERMINSTANCE
+DESCRIPTION "NCurses-4-2-981212, module panel"
+CODE LOADONCALL
+DATA LOADONCALL NONSHARED MULTIPLE
+EXPORTS
+ "_nc_calculate_obscure" @16 NONAME
+ "_nc_free_obscure" @17 NONAME
+ "_nc_override" @18 NONAME
+ "_nc_panel_is_linked" @19 NONAME
+ "_nc_panel_link_bottom" @20 NONAME
+ "bottom_panel" @7 NONAME
+ "del_panel" @5 NONAME
+ "hide_panel" @3 NONAME
+ "move_panel" @13 NONAME
+ "new_panel" @8 NONAME
+ "panel_above" @9 NONAME
+ "panel_below" @10 NONAME
+ "panel_hidden" @15 NONAME
+ "panel_userptr" @12 NONAME
+ "panel_window" @1 NONAME
+ "replace_panel" @14 NONAME
+ "set_panel_userptr" @11 NONAME
+ "show_panel" @4 NONAME
+ "top_panel" @6 NONAME
+ "update_panels" @2 NONAME
diff --git a/contrib/ncurses/misc/panel.ref b/contrib/ncurses/misc/panel.ref
new file mode 100644
index 000000000000..e84045a1047d
--- /dev/null
+++ b/contrib/ncurses/misc/panel.ref
@@ -0,0 +1,18 @@
+LIBRARY panel2 INITINSTANCE
+DESCRIPTION 'NCurses 1.9.9e-1 for OS/2 - panel library'
+EXPORTS
+ "panel_window" @1
+ "update_panels" @2
+ "hide_panel" @3
+ "show_panel" @4
+ "del_panel" @5
+ "top_panel" @6
+ "bottom_panel" @7
+ "new_panel" @8
+ "panel_above" @9
+ "panel_below" @10
+ "set_panel_userptr" @11
+ "panel_userptr" @12
+ "move_panel" @13
+ "replace_panel" @14
+ "panel_hidden" @15
diff --git a/contrib/ncurses/misc/run_tic.sh b/contrib/ncurses/misc/run_tic.sh
new file mode 100755
index 000000000000..a5170773b09c
--- /dev/null
+++ b/contrib/ncurses/misc/run_tic.sh
@@ -0,0 +1,159 @@
+#!/bin/sh
+##############################################################################
+# Copyright (c) 1998 Free Software Foundation, Inc. #
+# #
+# Permission is hereby granted, free of charge, to any person obtaining a #
+# copy of this software and associated documentation files (the "Software"), #
+# to deal in the Software without restriction, including without limitation #
+# the rights to use, copy, modify, merge, publish, distribute, distribute #
+# with modifications, sublicense, and/or sell copies of the Software, and to #
+# permit persons to whom the Software is furnished to do so, subject to the #
+# following conditions: #
+# #
+# The above copyright notice and this permission notice shall be included in #
+# all copies or substantial portions of the Software. #
+# #
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR #
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, #
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL #
+# THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER #
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING #
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER #
+# DEALINGS IN THE SOFTWARE. #
+# #
+# Except as contained in this notice, the name(s) of the above copyright #
+# holders shall not be used in advertising or otherwise to promote the sale, #
+# use or other dealings in this Software without prior written #
+# authorization. #
+##############################################################################
+#
+# Author: Thomas E. Dickey <dickey@clark.net> 1996
+#
+# $Id: run_tic.sh,v 1.10 1998/05/31 00:29:34 mooney Exp $
+# This script is used to install terminfo.src using tic. We use a script
+# because the path checking is too awkward to do in a makefile.
+#
+# Parameters:
+# $1 = nominal directory in which to find 'tic', i.e., $(bindir).
+# $2 = source-directory, i.e., $(srcdir)
+# $3 = destination-directory path, i.e., $(ticdir)
+# $4 = install-prefix, if any
+#
+# Assumes:
+# The leaf directory names (bin, lib, shared, tabset, terminfo)
+#
+echo '** Building terminfo database, please wait...'
+#
+# Parameter parsing is primarily for debugging. The script is designed to
+# be run from the misc/Makefile as
+# make install.data
+prefix=/usr/local
+if test $# != 0 ; then
+ bindir=$1
+ shift
+ PREFIX=`echo $bindir | sed -e 's/\/bin$//'`
+ test -n "$PREFIX" && test "x$PREFIX" != "x$bindir" && prefix=$PREFIX
+else
+ bindir=$prefix/bin
+fi
+
+if test $# != 0 ; then
+ srcdir=$1
+ shift
+else
+ srcdir=.
+fi
+
+if test $# != 0 ; then
+ ticdir=$1
+ shift
+else
+ ticdir=$prefix/share/terminfo
+fi
+
+if test $# != 0 ; then
+ IP=$1
+ shift
+else
+ IP=""
+fi
+
+# Allow tic to run either from the install-path, or from the build-directory
+case "$PATH" in
+:*) PATH=../progs:$IP$bindir$PATH ;;
+*) PATH=../progs:$IP$bindir:$PATH ;;
+esac
+export PATH
+
+#
+# set another env var that doesn't get reset when `shlib' runs, so `shlib' uses
+# the PATH we just set.
+#
+NEWPATH=$PATH
+export NEWPATH
+PROG_BIN_DIR=$IP$bindir
+export PROG_BIN_DIR
+
+TERMINFO=$IP$ticdir ; export TERMINFO
+umask 022
+
+# Construct the name of the old (obsolete) pathname, e.g., /usr/lib/terminfo.
+TICDIR=`echo $TERMINFO | sed -e 's/\/share\//\/lib\//'`
+
+# Remove the old terminfo stuff; we don't care if it existed before, and it
+# would generate a lot of confusing error messages if we tried to overwrite it.
+# We explicitly remove its contents rather than the directory itself, in case
+# the directory is actually a symbolic link.
+( rm -fr $TERMINFO/[0-9A-Za-z] 2>/dev/null )
+
+# If we're not installing into /usr/share/, we'll have to adjust the location
+# of the tabset files in terminfo.src (which are in a parallel directory).
+TABSET=`echo $ticdir | sed -e 's/\/terminfo$/\/tabset/'`
+SRC=$srcdir/terminfo.src
+if test "x$TABSET" != "x/usr/share/tabset" ; then
+ echo '** adjusting tabset paths'
+ TMP=${TMPDIR-/tmp}/$$
+ sed -e s:/usr/share/tabset:$TABSET:g $SRC >$TMP
+ trap "rm -f $TMP" 0 1 2 5 15
+ SRC=$TMP
+fi
+
+if ( $srcdir/shlib tic -s $SRC )
+then
+ echo '** built new '$TERMINFO
+else
+ echo '? tic could not build '$TERMINFO
+ exit 1
+fi
+
+# Make a symbolic link to provide compatibility with applications that expect
+# to find terminfo under /usr/lib. That is, we'll _try_ to do that. Not
+# all systems support symbolic links, and those that do provide a variety
+# of options for 'test'.
+if test "$TICDIR" != "$TERMINFO" ; then
+ ( rm -f $TICDIR 2>/dev/null )
+ if ( cd $TICDIR 2>/dev/null )
+ then
+ cd $TICDIR
+ TICDIR=`pwd`
+ if test $TICDIR != $TERMINFO ; then
+ # Well, we tried. Some systems lie to us, so the
+ # installer will have to double-check.
+ echo "Verify if $TICDIR and $TERMINFO are the same."
+ echo "The new terminfo is in $TERMINFO; the other should be a link to it."
+ echo "Otherwise, remove $TICDIR and link it to $TERMINFO."
+ fi
+ else
+ cd $IP$prefix
+ # Construct a symbolic link that only assumes $ticdir has the
+ # same $prefix as the other installed directories.
+ RELATIVE=`echo $ticdir|sed -e 's:^'$prefix'/::'`
+ if test "$RELATIVE" != "$ticdir" ; then
+ RELATIVE=../`echo $ticdir|sed -e 's:^'$prefix'/::' -e 's:^/::'`
+ fi
+ if ( ln -s $RELATIVE $TICDIR )
+ then
+ echo '** linked '$TICDIR' for compatibility'
+ fi
+ fi
+fi
diff --git a/contrib/ncurses/misc/shlib b/contrib/ncurses/misc/shlib
new file mode 100755
index 000000000000..ee55062283f7
--- /dev/null
+++ b/contrib/ncurses/misc/shlib
@@ -0,0 +1,82 @@
+#!/bin/sh
+##############################################################################
+# Copyright (c) 1998 Free Software Foundation, Inc. #
+# #
+# Permission is hereby granted, free of charge, to any person obtaining a #
+# copy of this software and associated documentation files (the "Software"), #
+# to deal in the Software without restriction, including without limitation #
+# the rights to use, copy, modify, merge, publish, distribute, distribute #
+# with modifications, sublicense, and/or sell copies of the Software, and to #
+# permit persons to whom the Software is furnished to do so, subject to the #
+# following conditions: #
+# #
+# The above copyright notice and this permission notice shall be included in #
+# all copies or substantial portions of the Software. #
+# #
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR #
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, #
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL #
+# THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER #
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING #
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER #
+# DEALINGS IN THE SOFTWARE. #
+# #
+# Except as contained in this notice, the name(s) of the above copyright #
+# holders shall not be used in advertising or otherwise to promote the sale, #
+# use or other dealings in this Software without prior written #
+# authorization. #
+##############################################################################
+#
+# Author: Thomas E. Dickey <dickey@clark.net> 1996
+#
+# $Id: shlib,v 1.5 1998/05/31 00:29:38 mooney Exp $
+# Use this script as a wrapper when running executables linked to shared
+# libraries on systems that use the $LD_LIBRARY_PATH variable and don't embed
+# the soname's path within the linked executable (such as IRIX), e.g,
+#
+# shlib knight
+#
+# Setting LD_LIBRARY_PATH, overrides/supplements the loader's normal search
+# path, and works on most systems. The drawback is that then the environment
+# variable has to be set to run the programs within this directory tree.
+#
+# For Linux (and other systems using the GNU loader), we can use the rpath
+# directive, which embeds the pathname of the library within the executable.
+# Using the Linux loader's rpath directive introduces a constraint, since
+# it's embedded into the binary, and means that the binary cannot be moved
+# around (though it'll work if the $exec_prefix convention that puts the bin
+# and lib directories under the same parent is followed).
+#
+# Using the actual soname (e.g., ../lib/libncurses.so) alone, is a more
+# flexible solution; you can link without having to set the environment
+# variable, and on some systems (IRIX) you can even run the resulting binaries
+# without setting LD_LIBRARY_PATH.
+#
+# Using a conventional link, with -L and -l options on Linux results in a
+# statically linked executable, which we don't want at all.
+#
+
+#
+# Make sure that we use the PATH that was set in run_tic.sh
+#
+if test X$NEWPATH != X ; then
+ PATH=$NEWPATH
+ export PATH
+fi
+
+q=""
+for p in lib ../lib
+do
+ if test -d $p; then
+ q="$p"
+ fi
+done
+if test -n "$q" ; then
+ if test -n "$LD_LIBRARY_PATH"; then
+ LD_LIBRARY_PATH="$q:$LD_LIBRARY_PATH"
+ else
+ LD_LIBRARY_PATH="$q"
+ fi
+ export LD_LIBRARY_PATH
+fi
+eval "$*"
diff --git a/contrib/ncurses/misc/tabset/std b/contrib/ncurses/misc/tabset/std
new file mode 100644
index 000000000000..e93f737f0e35
--- /dev/null
+++ b/contrib/ncurses/misc/tabset/std
@@ -0,0 +1 @@
+ 3 1 1 1 1 1 1 1 1 1 1 1 1 1
diff --git a/contrib/ncurses/misc/tabset/stdcrt b/contrib/ncurses/misc/tabset/stdcrt
new file mode 100644
index 000000000000..66ba12f64da5
--- /dev/null
+++ b/contrib/ncurses/misc/tabset/stdcrt
@@ -0,0 +1 @@
+ 3 1 1 1 1 1 1 1 1 1 \ No newline at end of file
diff --git a/contrib/ncurses/misc/tabset/vt100 b/contrib/ncurses/misc/tabset/vt100
new file mode 100644
index 000000000000..8828d19da748
--- /dev/null
+++ b/contrib/ncurses/misc/tabset/vt100
@@ -0,0 +1,3 @@
+
+
+H H H H H H H H H H H H H H H H
diff --git a/contrib/ncurses/misc/tabset/vt300 b/contrib/ncurses/misc/tabset/vt300
new file mode 100644
index 000000000000..b1f9ce16d134
--- /dev/null
+++ b/contrib/ncurses/misc/tabset/vt300
@@ -0,0 +1,3 @@
+
+
+P2$t9/17/25/33/41/49/57/65/73/81/89/97/105/113/121/129\
diff --git a/contrib/ncurses/misc/tdlint b/contrib/ncurses/misc/tdlint
new file mode 100755
index 000000000000..869a34bf9222
--- /dev/null
+++ b/contrib/ncurses/misc/tdlint
@@ -0,0 +1,111 @@
+#!/bin/sh
+##############################################################################
+# Copyright (c) 1998 Free Software Foundation, Inc. #
+# #
+# Permission is hereby granted, free of charge, to any person obtaining a #
+# copy of this software and associated documentation files (the "Software"), #
+# to deal in the Software without restriction, including without limitation #
+# the rights to use, copy, modify, merge, publish, distribute, distribute #
+# with modifications, sublicense, and/or sell copies of the Software, and to #
+# permit persons to whom the Software is furnished to do so, subject to the #
+# following conditions: #
+# #
+# The above copyright notice and this permission notice shall be included in #
+# all copies or substantial portions of the Software. #
+# #
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR #
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, #
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL #
+# THE ABOVE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER #
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING #
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER #
+# DEALINGS IN THE SOFTWARE. #
+# #
+# Except as contained in this notice, the name(s) of the above copyright #
+# holders shall not be used in advertising or otherwise to promote the sale, #
+# use or other dealings in this Software without prior written #
+# authorization. #
+##############################################################################
+#
+# Author: Thomas E. Dickey <dickey@clark.net> 1996
+#
+# $Id: tdlint,v 1.4 1998/02/11 12:13:50 tom Exp $
+#
+# Lint-script that allows user's own lint libraries, in addition to the ones
+# installed in the system.
+#
+OPT=""
+DIRS=""
+LIBS=""
+FILES=""
+ARCH=`uname -s`
+if test -z "$ARCH" ; then
+ echo '? uname not found'
+ exit 1
+else
+ case $ARCH in
+ AIX) set - $* -Nn4000
+ ;;
+ IRIX) set - $* -n -lc
+ ;;
+ SunOS)
+ case `uname -r` in
+ 5.*) ARCH=Solaris
+ set - $* -n -lc
+ ;;
+ esac
+ ;;
+ esac
+fi
+# LIBDIR=$HOME/lib/$ARCH/lint ;export LIBDIR
+for p in $HOME/lib/$ARCH/lint /usr/lib/lint /usr/lib
+do
+ if [ -d $p ]
+ then
+ DIRS="$DIRS $p"
+ fi
+done
+#
+while [ $# != 0 ]
+do
+ case $1 in
+ -D*\"*) ;;
+ -L*)
+ DIRS="`echo $1|sed -e 's/^-L//'` $DIRS"
+ ;;
+ -l*)
+ lib="llib-l`echo $1 | sed -e 's/^-l//'`.ln"
+ found=no
+ for p in $DIRS
+ do
+ echo -n testing $p/$lib
+ if [ -f $p/$lib ]
+ then
+ LIBS="$LIBS $p/$lib"
+ echo " (ok)"
+ found=yes
+ break
+ fi
+ echo
+ done
+ if [ $found = no ]
+ then
+ echo "ignored library $1"
+ fi
+ ;;
+ -n) if [ -z "$OPT" ]
+ then
+ OPT="-I."
+ fi
+ OPT="$OPT $1"
+ ;;
+ -*) OPT="$OPT $1"
+ ;;
+ *)
+ FILES="$FILES $1"
+ ;;
+ esac
+ shift
+done
+#
+eval lint $OPT $FILES $LIBS
diff --git a/contrib/ncurses/misc/terminfo.src b/contrib/ncurses/misc/terminfo.src
new file mode 100644
index 000000000000..3ef04c95d389
--- /dev/null
+++ b/contrib/ncurses/misc/terminfo.src
@@ -0,0 +1,17257 @@
+######## TERMINAL TYPE DESCRIPTIONS SOURCE FILE
+#
+# This version of terminfo.src is distributed with ncurses.
+#
+# Version 10.2.1
+# $Date: 1999/08/22 00:05:28 $
+# terminfo syntax
+#
+# Eric S. Raymond (current maintainer)
+# John Kunze, Berkeley
+# Craig Leres, Berkeley
+#
+# Please e-mail changes to terminfo@ccil.org; the old termcap@berkeley.edu
+# address is no longer valid. The latest version can always be found at
+# <http://earthspace.net/terminfo>.
+#
+# PURPOSE OF THIS FILE:
+#
+# This file describes the capabilities of various character-cell terminals,
+# as needed by software such as screen-oriented editors.
+#
+# Other terminfo and termcap files exist, supported by various OS vendors
+# or as relics of various older versions of UNIX. This one is the longest
+# and most comprehensive one in existence. It subsumes not only the entirety
+# of the historical 4.4BSD, GNU, System V and SCO termcap files and the BRL
+# termcap file, but also large numbers of vendor-maintained termcap and
+# terminfo entries more complete and carefully tested than those in historical
+# termcap/terminfo versions.
+#
+# Pointers to related resources (including the ncurses distribution) may
+# be found at <http://earthspace.net/terminfo>.
+#
+# INTERNATIONALIZATION:
+#
+# This file uses only the US-ASCII character set (no ISO8859 characters).
+#
+# This file assumes a US-ASCII character set. If you need to fix this, start
+# by global-replacing \E(B and \E)B with the appropriate ISO 6429 enablers
+# for your character set. \E(A and \E)A enables the British character set
+# with the pound sign at position 2/3.
+#
+# In a Japanese-processing environment using EUC/Japanese or Shift-JIS,
+# C1 characters are considered the first-byte set of the Japanese encodings,
+# so \E)0 should be avoided in <enacs> and initialization strings.
+#
+# FILE FORMAT:
+#
+# The version you are looking at may be in any of three formats: master
+# (terminfo with OT capabilities), stock terminfo, or termcap. You can tell
+# which by the format given in the header above.
+#
+# The master format is accepted and generated by the terminfo tools in the
+# ncurses suite; it differs from stock (System V-compatible) terminfo only
+# in that it admits a group of capabilities (prefixed `OT') equivalent to
+# various obsolete termcap capabilities. You can, thus, convert from master
+# to stock terminfo simply by filtering with `sed "/OT[^,]*,/s///"'; but if
+# you have ncurses `tic -I' is nicer (among other things, it automatically
+# outputs entries in a canonical form).
+#
+# The termcap version is generated automatically from the master version
+# using tic -C. This filtering leaves in the OT capabilities under their
+# original termcap names. All translated entries fit within the 1023-byte
+# string-table limit of archaic termcap libraries except where explicitly
+# noted below. Note that the termcap translation assumes that your termcap
+# library can handle multiple tc capabilities in an entry. 4.4BSD has this
+# capability. Older versions of GNU termcap, through 1.3, do not.
+#
+# For details on these formats, see terminfo(5) in the ncurses distribution,
+# and termcap(5) in the 4.4BSD Unix Programmer's Manual. Be aware that 4.4BSD
+# curses has been declared obsolete by the caretakers of the 4.4BSD sources
+# as of June 1995; they are encouraging everyone to migrate to ncurses.
+#
+# Note: unlike some other distributed terminfo files (Novell Unix & SCO's),
+# no entry in this file has embedded comments. This is so source translation
+# to termcap only has to carry over leading comments. Also, no name field
+# contains embedded whitespace (such whitespace confuses rdist).
+#
+# Further note: older versions of this file were often installed with an editor
+# script (reorder) that moved the most common terminal types to the front of
+# the file. This should no longer be necessary, as the file is now ordered
+# roughly by type frequency with ANSI/VT100 and other common types up front.
+#
+# Some information has been merged in from terminfo files distributed by
+# USL and SCO (see COPYRIGHTS AND OTHER DELUSIONS below). Much information
+# comes from vendors who maintain official terminfos for their hardware
+# (notably DEC and Wyse).
+#
+# A detailed change history is included at the end of this file.
+#
+# FILE ORGANIZATION:
+#
+# Comments in this file begin with # - they cannot appear in the middle
+# of a terminfo/termcap entry (this feature had to be sacrificed in order
+# to allow standard terminfo and termcap syntax to be generated cleanly from
+# the master format). Individual capabilities are commented out by
+# placing a period between the colon and the capability name.
+#
+# The file is divided up into major sections (headed by lines beginning with
+# the string "########") and minor sections (beginning with "####"); do
+#
+# grep "^####" <file> | more
+#
+# to see a listing of section headings. The intent of the divisions is
+# (a) to make it easier to find things, and (b) to order the database so
+# that important and frequently-encountered terminal types are near the
+# front (so that you'll get reasonable search efficiency from a linear
+# search of the termcap form even if you don't use reorder). Minor sections
+# usually correspond to manufacturers or standard terminal classes.
+# Parenthesized words following manufacturer names are type prefixes or
+# product line names used by that manufacturers.
+#
+# HOW TO READ THE ENTRIES:
+#
+# The first name in an entry is the canonical name for the model or
+# type, last entry is a verbose description. Others are mnemonic synonyms for
+# the terminal.
+#
+# Terminal names look like <manufacturer> <model> - <modes/options>
+# The part to the left of the dash, if a dash is present, describes the
+# particular hardware of the terminal. The part to the right may be used
+# for flags indicating special ROMs, extra memory, particular terminal modes,
+# or user preferences.
+#
+# All names should be in lower case, for consistency in typing.
+#
+# The following are conventionally used suffixes:
+# -2p Has two pages of memory. Likewise 4p, 8p, etc.
+# -am Enable auto-margin.
+# -m Monochrome. Suppress color support
+# -mc Magic-cookie. Some terminals (notably older Wyses) can
+# only support one attribute without magic-cookie lossage.
+# Their base entry is usually paired with another that
+# uses magic cookies to support multiple attributes.
+# -nam No auto-margin - suppress <am> capability
+# -nl No labels - suppress soft labels
+# -ns No status line - suppress status line
+# -rv Terminal in reverse video mode (black on white)
+# -s Enable status line.
+# -vb Use visible bell (<flash>) rather than <bel>.
+# -w Wide - in 132 column mode.
+# If a name has multiple suffixes and one is a line height, that one should
+# go first. Thus `aaa-30-s-rv' is recommended over `aaa-s-rv-30'.
+#
+# Entries with embedded plus signs are designed to be included through use/tc
+# capabilities, not used as standalone entries.
+#
+# To avoid search clashes, some older all-numeric names for terminals have
+# been removed (i.e., "33" for the Model 33 Teletype, "2621" for the HP2621).
+# All primary names of terminals now have alphanumeric prefixes.
+#
+# Comments marked "esr" are mostly results of applying the termcap-compiler
+# code packaged with ncurses and contemplating the resulting error messages.
+# In many cases, these indicated obvious fixes to syntax garbled by the
+# composers. In a few cases, I was able to deduce corrected forms for garbled
+# capabilities by looking at context. All the information in the original
+# entries is preserved in the comments.
+#
+# In the comments, terminfo capability names are bracketed with <> (angle
+# brackets). Termcap capability names are bracketed with :: (colons).
+#
+# INTERPRETATION OF USER CAPABILITIES
+#
+# The System V Release 4 and XPG4 terminfo format defines ten string
+# capabilities for use by applications, <u0>...<u9>. In this file, we use
+# certain of these capabilities to describe functions which are not covered
+# by terminfo. The mapping is as follows:
+#
+# u9 terminal enquire string (equiv. to ANSI/ECMA-48 DA)
+# u8 terminal answerback description
+# u7 cursor position request (equiv. to VT100/ANSI/ECMA-48 DSR 6)
+# u6 cursor position report (equiv. to ANSI/ECMA-48 CPR)
+#
+# The terminal enquire string <u9> should elicit an answerback response
+# from the terminal. Common values for <u9> will be ^E (on older ASCII
+# terminals) or \E[c (on newer VT100/ANSI/ECMA-48-compatible terminals).
+#
+# The cursor position request (<u7>) string should elicit a cursor position
+# report. A typical value (for VT100 terminals) is \E[6n.
+#
+# The terminal answerback description (u8) must consist of an expected
+# answerback string. The string may contain the following scanf(3)-like
+# escapes:
+#
+# %c Accept any character
+# %[...] Accept any number of characters in the given set
+#
+# The cursor position report (<u6>) string must contain two scanf(3)-style
+# %d format elements. The first of these must correspond to the Y coordinate
+# and the second to the %d. If the string contains the sequence %i, it is
+# taken as an instruction to decrement each value after reading it (this is
+# the inverse sense from the cup string). The typical CPR value is
+# \E[%i%d;%dR (on VT100/ANSI/ECMA-48-compatible terminals).
+#
+# These capabilities are used by tac(1m), the terminfo action checker soon
+# to be distributed with ncurses.
+#
+# TABSET FILES
+#
+# All the entries in this file have been edited to assume that the tabset
+# files directory is /usr/share/tabset, in conformance with the File Hierarchy
+# Standard for Linux and open-source BSD systems. Some vendors (notably Sun)
+# use /usr/lib/tabset or (more recently) /usr/share/lib/tabset.
+#
+# No curses package we know of actually uses these files. If their location
+# is an issue, you will have to hand-patch the file locations before compiling
+# this file.
+#
+# REQUEST FOR CONTACT INFORMATION AND HISTORICAL MATERIAL
+#
+# As the ANSI/ECMA-48 standard and variants take firmer hold, and as
+# character-cell terminals are increasingly replaced by X displays, much of
+# this file is becoming a historical document (this is part of the reason for
+# the new organization, which puts ANSI types, xterm, free-Unix consoles,
+# and vt100 up front in confidence that this will catch 95% of new hardware).
+#
+# For the terminal types still alive, I'd like to have manufacturer's
+# contact data (Internet address and/or snail-mail + phone).
+#
+# I'm also interested in enriching the comments so that the latter portions of
+# the file do in fact become a potted history of VDT technology as seen by
+# UNIX hackers. Ideally, I'd like the headers for each manufacturer to
+# include its live/dead/out-of-the-business status, and for as many
+# terminal types as possible to be tagged with information like years
+# of heaviest use, popularity, and interesting features.
+#
+# I'm especially interested in identifying the obscure entries listed under
+# `Miscellaneous obsolete terminals, manufacturers unknown' before the tribal
+# wisdom about them gets lost. If you know a lot about obscure old terminals,
+# please go to the terminfo resource page, grab the UFO file (ufo.ti), and
+# eyeball it for things you can identify and describe.
+#
+# If you have been around long enough to contribute, please read the file
+# with this in mind and send me your annotations.
+#
+# COPYRIGHTS AND OTHER DELUSIONS
+#
+# The BSD ancestor of this file had a standard Regents of the University of
+# California copyright with dates from 1980 to 1993.
+#
+# Some information has been merged in from a terminfo file SCO distributes.
+# It has an obnoxious boilerplate copyright which I'm ignoring because they
+# took so much of the content from the ancestral BSD versions of this file
+# and didn't attribute it, thereby violating the BSD Regents' copyright.
+#
+# Not that anyone should care. However many valid functions copyrights may
+# serve, putting one on a termcap/terminfo file with hundreds of anonymous
+# contributors makes about as much sense as copyrighting a wall-full of
+# graffiti -- it's legally dubious, ethically bogus, and patently ridiculous.
+#
+# This file deliberately has no copyright. It belongs to no one and everyone.
+# If you claim you own it, you will merely succeed in looking like a fool.
+# Use it as you like. Use it at your own risk. Copy and redistribute freely.
+# There are no guarantees anywhere. Svaha!
+#
+
+######## ANSI, UNIX CONSOLE, AND SPECIAL TYPES
+#
+# This section describes terminal classes and maker brands that are still
+# quite common.
+#
+
+#### Specials
+#
+# Special "terminals". These are used to label tty lines when you don't
+# know what kind of terminal is on it. The characteristics of an unknown
+# terminal are the lowest common denominator - they look about like a ti 700.
+#
+
+dumb|80-column dumb tty,
+ am,
+ cols#80,
+ bel=^G, cr=^M, cud1=^J, ind=^J,
+unknown|unknown terminal type,
+ gn, use=dumb,
+lpr|printer|line printer,
+ hc, os,
+ cols#132, lines#66,
+ bel=^G, cr=^M, cub1=^H, cud1=^J, ff=^L, ind=^J,
+glasstty|classic glass tty interpreting ASCII control characters,
+ am,
+ cols#80,
+ bel=^G, clear=^L, cr=^M, cub1=^H, cud1=^J, ht=^I, kbs=^H,
+ kcub1=^H, kcud1=^J, nel=^M^J,
+
+#### ANSI.SYS/ISO 6429/ECMA-48 Capabilities
+#
+# See the end-of-file comment for more on these.
+#
+
+# The IBM PC alternate character set. Plug this into any Intel console entry.
+# We use \E[11m for rmacs rather than \E[12m so the <acsc> string can use the
+# ROM graphics for control characters such as the diamond, up- and down-arrow.
+# This works with the System V, Linux, and BSDI consoles. It's a safe bet this
+# will work with any Intel console, they all seem to have inherited \E[11m
+# from the ANSI.SYS de-facto standard.
+klone+acs|alternate character set for ansi.sys displays,
+ acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,
+ rmacs=\E[10m, smacs=\E[11m,
+
+# Highlight controls corresponding to the ANSI.SYS standard. Most
+# console drivers for Intel boxes obey these. Makes the same assumption
+# about \E[11m as klone+acs. True ANSI/ECMA-48 would have <rmso=\E[27m>,
+# <rmul=\E[24m>, but this isn't a documented feature of ANSI.SYS.
+klone+sgr|attribute control for ansi.sys displays,
+ blink=\E[5m, bold=\E[1m, invis=\E[8m, rev=\E[7m,
+ rmpch=\E[10m, rmso=\E[m, rmul=\E[m,
+ sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m,
+ sgr0=\E[0;10m, smpch=\E[11m, smso=\E[7m, smul=\E[4m,
+ use=klone+acs,
+
+# Highlight controls corresponding to the ANSI.SYS standard. *All*
+# console drivers for Intel boxes obey these. Does not assume \E[11m will
+# work; uses \E[12m instead, which is pretty bulletproof but loses you the ACS
+# diamond and arrow characters under curses.
+klone+sgr-dumb|attribute control for ansi.sys displays (no ESC [ 11 m),
+ blink=\E[5m, bold=\E[1m, invis=\E[8m, rev=\E[7m, rmso=\E[m,
+ rmul=\E[m,
+ sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;12%;m,
+ sgr0=\E[0;10m, smacs=\E[12m, smso=\E[7m, smul=\E[4m,
+ use=klone+acs,
+
+# KOI8-R (RFC1489) acs (alternate character set)
+# From: Qing Long <qinglong@Bolizm.ihep.su>, 24 Feb 1996.
+klone+koi8acs|alternate character set for ansi.sys displays with KOI8 charset,
+ acsc=+\020\,\021-\036.^_0\215`\004a\237f\234g\232h\222i\220j\205k\203l\202m\204n\212o\213p\216q\0r\217s\214t\206u\207v\210w\211x\201y\230z\231{\267|\274}L~\225,
+ rmacs=\E[10m, smacs=\E[11m,
+
+# ANSI.SYS color control. The setab/setaf caps depend on the coincidence
+# between SVr4/XPG4's color numbers and ANSI.SYS attributes. Here are longer
+# but equivalent strings that don't rely on that coincidence:
+# setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+# setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+# The DOS 5 manual asserts that these sequences meet the ISO 6429 standard.
+# They match a subset of ECMA-48.
+klone+color|color control for ansi.sys and ISO6429-compatible displays,
+ colors#8, ncv#3, pairs#64,
+ op=\E[37;40m, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
+
+# This is better than klone+color, it doesn't assume white-on-black as the
+# default color pair, but many `ANSI' terminals don't grok the <op> cap.
+ecma+color|color control for ECMA-48-compatible terminals,
+ colors#8, ncv#3, pairs#64,
+ op=\E[39;49m, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
+
+# Attribute control for ECMA-48-compatible terminals
+ecma+sgr|attribute capabilities for true ECMA-48 terminals,
+ rmso=\E[27m, rmul=\E[24m,
+ use=klone+sgr,
+
+# For comparison, here are all the capabilities implied by the Intel
+# Binary Compatibility Standard (level 2) that fit within terminfo.
+# For more detail on this rather pathetic standard, see the comments
+# near the end of this file.
+ibcs2|Intel Binary Compatibility Standard prescriptions,
+ cbt=\E[Z, clear=\Ec, cub=\E[%p1%dD, cud=\E[%p1%dB,
+ cuf=\E[%p1%dC, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA,
+ dch=\E[%p1%dP, dispc=\E=%p1%dg, ech=\E[%p1%dX,
+ hpa=\E[%i%p1%dG, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL,
+ indn=\E[%p1%dS, rc=\E7, rin=\E[%p1%dT, rmam=\E[?7l, sc=\E7,
+ smam=\E[?7h, tbc=\E[g, vpa=\E[%i%p1%dd,
+
+#### ANSI/ECMA-48 terminals and terminal emulators
+#
+# See near the end of this file for details on ANSI conformance.
+# Don't mess with these entries! Lots of other entries depend on them!
+#
+# This section lists entries in a least-capable to most-capable order.
+# if you're in doubt about what `ANSI' matches yours, try them in that
+# order and back off from the first that breaks.
+
+ansi-mini|any ansi terminal with pessimistic assumptions,
+ am,
+ cols#80, it#8, lines#24,
+ clear=\E[H\E[2J$<50>, cub1=\E[D, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, el=\E[K, home=\E[H,
+ ht=^I,
+
+# ANSI X3.64 from emory!mlhhh (Hugh Hansard) via BRL
+#
+# The following is an entry for the full ANSI 3.64 (1977). It lacks
+# padding, but most terminals using the standard are "fast" enough
+# not to require any -- even at 9600 bps. If you encounter problems,
+# try including the padding specifications.
+#
+# Note: the :as: and :ae: specifications are not implemented here, for
+# the available termcap documentation does not make clear WHICH alternate
+# character set to specify. ANSI 3.64 seems to make allowances for several.
+# Please make the appropriate adjustments to fit your needs -- that is
+# if you will be using alternate character sets.
+#
+# There are very few terminals running the full ANSI 3.64 standard,
+# so I could only test this entry on one verified terminal (Visual 102).
+# I would appreciate the results on other terminals sent to me.
+#
+# Please report comments, changes, and problems to:
+#
+# U.S. MAIL: Hugh Hansard
+# Box: 22830
+# Emory University
+# Atlanta, GA. 30322.
+#
+# USENET {akgua,msdc,sb1,sb6,gatech}!emory!mlhhh.
+#
+ansi77|ansi 3.64 standard 1977 version,
+ am, mir,
+ cols#80, it#8, lines#24,
+ bel=^G, clear=\E[;H\E[2J, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=\E[B, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A, dch1=\E[P, dl1=\E[M$<5*/>, ed=\E[J, el=\E[K,
+ home=\E[H, ht=^I, il1=\E[L$<5*/>, ind=\ED, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kf1=\EOP,
+ kf2=\EOR, kf4=\EOS, khome=\E[H, nel=^M\ED, ri=\EM,
+ rmir=\E[4l, rmso=\E[m, rmul=\E[m, smir=\E[4h, smso=\E[7m,
+ smul=\E[4m,
+
+# Procomm and some other ANSI emulations don't recognize all of the ANSI-
+# standard capabilities. This entry deletes <cuu>, <cuf>, <cud>, <cub>, and
+# <vpa>/<hpa> capabilities, forcing curses to use repetitions of <cuu1>,
+# <cuf1>, <cud1> and <cub1>. Also deleted <ich> and <ich1>, as QModem up to
+# 5.03 doesn't recognize these. Finally, we delete <rep> and <ri>, which seem
+# to confuse many emulators. On the other hand, we can count on these programs
+# doing <rmacs>/<smacs>/<sgr>. Older versions of this entry featured
+# <invis=\E[9m>, but <invis=\E[8m> now seems to be more common under
+# ANSI.SYS influence.
+# From: Eric S. Raymond <esr@snark.thyrsus.com> Oct 30 1995
+pcansi-m|pcansi-mono|ibm-pc terminal programs claiming to be ansi (mono mode),
+ am, mir, msgr,
+ cols#80, it#8, lines#24,
+ bel=^G, cbt=\E[Z, clear=\E[H\E[J, cr=^M, cub1=\E[D,
+ cud1=\E[B, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
+ dch1=\E[P, dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, ht=^I,
+ hts=\EH, il1=\E[L, ind=^J, kbs=^H, kcub1=\E[D, kcud1=\E[B,
+ kcuf1=\E[C, kcuu1=\E[A, khome=\E[H, tbc=\E[2g,
+ use=klone+sgr-dumb,
+pcansi-25-m|pcansi25m|ibm-pc terminal programs with 25 lines (mono mode),
+ lines#25, use=pcansi-m,
+pcansi-33-m|pcansi33m|ibm-pc terminal programs with 33 lines (mono mode),
+ lines#33, use=pcansi-m,
+pcansi-43-m|ansi43m|ibm-pc terminal programs with 43 lines (mono mode),
+ lines#43, use=pcansi-m,
+# The color versions. All PC emulators do color...
+pcansi|ibm-pc terminal programs claiming to be ansi,
+ use=klone+color, use=pcansi-m,
+pcansi-25|pcansi25|ibm-pc terminal programs with 25 lines,
+ lines#25, use=pcansi,
+pcansi-33|pcansi33|ibm-pc terminal programs with 33 lines,
+ lines#33, use=pcansi,
+pcansi-43|pcansi43|ibm-pc terminal programs with 43 lines,
+ lines#43, use=pcansi,
+
+# ansi-m -- full ANSI X3.64 with ANSI.SYS-compatible attributes, no color.
+# If you want pound signs rather than dollars, replace `B' with `A'
+# in the <s0ds>, <s1ds>, <s2ds>, and <s3ds> capabilities.
+# From: Eric S. Raymond <esr@snark.thyrsus.com> Nov 6 1995
+ansi-m|ansi-mono|ANSI X3.64-1979 terminal with ANSI.SYS compatible attributes,
+ mc5i,
+ cub=\E[%p1%dD, cud=\E[%p1%dB, cuf=\E[%p1%dC,
+ cuu=\E[%p1%dA, dch=\E[%p1%dP, dl=\E[%p1%dM,
+ ech=\E[%p1%dX, el1=\E[1K, hpa=\E[%i%p1%dG, ht=\E[I,
+ ich=\E[%p1%d@, il=\E[%p1%dL, indn=\E[%p1%dS, kbs=^H,
+ kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kich1=\E[L, mc4=\E[4i, mc5=\E[5i, nel=\r\E[S,
+ rep=%p1%c\E[%p2%{1}%-%db, rin=\E[%p1%dT, s0ds=\E(B,
+ s1ds=\E)B, s2ds=\E*B, s3ds=\E+B, tbc=\E[2g,
+ vpa=\E[%i%p1%dd, use=pcansi-m,
+
+# ansi -- this terminfo expresses the largest subset of X3.64 that will fit in
+# standard terminfo. Assumes ANSI.SYS-compatible attributes and color.
+# From: Eric S. Raymond <esr@snark.thyrsus.com> Nov 6 1995
+ansi|ansi/pc-term compatible with color,
+ u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?%[;0123456789]c,
+ u9=\E[c,
+ use=ecma+color, use=klone+sgr, use=ansi-m,
+
+#### DOS ANSI.SYS variants
+#
+# This completely describes the sequences specified in the DOS 2.1 ANSI.SYS
+# documentation (except for the keyboard key reassignment feature, which
+# doen't fit the <pfkey> model well). The klone+acs sequences were valid
+# though undocumented. The <pfkey> capability is untested but should work for
+# keys F1-F10 (%p1 values outside this range will yield unpredictable results).
+# From: Eric S. Raymond <esr@snark.thyrsus.com> Nov 7 1995
+ansi.sys-old|ANSI.SYS under PC-DOS 2.1,
+ am, mir, msgr, xon,
+ cols#80, lines#25,
+ clear=\E[2J, cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, el=\E[k, home=\E[H,
+ is2=\E[m\E[?7h, kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K,
+ khome=^^, pfkey=\E[0;%p1%{58}%+%d;%p2"%s", rc=\E[u,
+ rmam=\E[?7l, sc=\E[s, smam=\E[?7h, u6=\E[%i%d;%dR,
+ u7=\E[6n,
+ use=klone+color, use=klone+sgr,
+ansi.sys|ANSI.SYS 3.1 and later versions,
+ el=\E[K, use=ansi.sys-old,
+
+#
+# Define IBM PC keypad keys for vi as per MS-Kermit while using ANSI.SYS.
+# This should only be used when the terminal emulator cannot redefine the keys.
+# Since redefining keys with ansi.sys also affects PC-DOS programs, the key
+# definitions must be restored. If the terminal emulator is quit while in vi
+# or others using <smkx>/<rmkx>, the keypad will not be defined as per PC-DOS.
+# The PgUp and PgDn are prefixed with ESC so that tn3270 can be used on Unix
+# (^U and ^D are already defined for tn3270). The ESC is safe for vi but it
+# does "beep". ESC ESC i is used for Ins to avoid tn3270 ESC i for coltab.
+# Note that <kcub1> is always BS, because PC-dos can tolerate this change.
+# Caution: vi is limited to 256 string bytes, longer crashes or weirds out vi.
+# Consequently the End keypad key could not be set (it is relatively safe and
+# actually useful because it sends ^@ O, which beeps and opens a line above).
+ansi.sysk|ansisysk|PC-DOS 3.1 ANSI.SYS with keypad redefined for vi,
+ is2=U2 PC-DOS 3.1 ANSI.SYS with keypad redefined for vi 9-29-86\n\E[;75;8p,
+ rmkx=\E[;71;0;71p\E[;72;0;72p\E[;73;0;73p\E[;77;0;77p\E[;80;0;80p\E[;81;0;81p\E[;82;0;82p\E[;83;0;83p,
+ smkx=\E[;71;30p\E[;72;11p\E[;73;27;21p\E[;77;12p\E[;80;10p\E[;81;27;4p\E[;82;27;27;105p\E[;83;127p,
+ use=ansi.sys,
+#
+# Adds ins/del line/character, hence vi reverse scrolls/inserts/deletes nicer.
+nansi.sys|nansisys|PC-DOS Public Domain NANSI.SYS,
+ dch1=\E[1P, dl1=\E[1M, ich1=\E[1@, il1=\E[1L,
+ is2=U3 PC-DOS Public Domain NANSI.SYS 9-23-86\n, use=ansi.sys,
+#
+# See ansi.sysk and nansi.sys above.
+nansi.sysk|nansisysk|PC-DOS Public Domain NANSI.SYS with keypad redefined for vi,
+ dch1=\E[1P, dl1=\E[1M, ich1=\E[1@, il1=\E[1L,
+ is2=U4 PC-DOS Public Domain NANSI.SYS with keypad redefined for vi 9-29-86\n\E[;75;8p,
+ use=ansi.sysk,
+
+#### ANSI console types
+#
+
+#### BeOS
+#
+# BeOS entry for Terminal program Seems to be almost ANSI
+beterm|BeOS Terminal,
+ am, eo, mir, msgr, xenl, xon,
+ colors#8, cols#80, it#8, lines#25, ncv#5, pairs#64,
+ bel=^G, blink=\E[5m, bold=\E[1m, clear=\E[H\E[J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch=\E[%p1%dP,
+ dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, flash=\E[?5h\E[?5l$<200/>, home=\E[H,
+ hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, invis=\E[8m, kb2=\E[G,
+ kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kend=\E[4~, kf1=\E[11~, kf10=\E[20~, kf11=\E[21~,
+ kf12=\E[22~, kf2=\E[12~, kf3=\E[13~, kf4=\E[14~,
+ kf5=\E[15~, kf6=\E[16~, kf7=\E[17~, kf8=\E[18~, kf9=\E[19~,
+ khome=\E[1~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~, kspd=^Z,
+ nel=^M^J, op=\E[m, rc=\E8, rev=\E[7m, ri=\EM, rmir=\E[4l,
+ rmso=\E[m, rmul=\E[24m, rs1=\Ec, sc=\E7, setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm, setb=\E[%p1%{40}%+%cm,
+ setf=\E[%p1%{30}%+%cm, sgr0=\E[0;10m, smir=\E[4h,
+ smso=\E[7m, smul=\E[4m, u6=\E[%i%p1%d;%p2%dR, u7=\E[6n,
+ u8=\E[?6c, u9=\E[c, vpa=\E[%i%p1%dd,
+
+#### Linux consoles
+#
+
+# This entry is good for the 1.2.13 or later version of the Linux console.
+#
+# ***************************************************************************
+# * *
+# * WARNING: *
+# * Linuxes come with a default keyboard mapping kcbt=^I. This entry, in *
+# * response to user requests, assumes kcbt=\E[Z, the ANSI/ECMA reverse-tab *
+# * character. Here are the keymap replacement lines that will set this up: *
+# * *
+# keycode 15 = Tab Tab
+# alt keycode 15 = Meta_Tab
+# shift keycode 15 = F26
+# string F26 ="\033[Z"
+# * *
+# * This has to use a key slot which is unfortunate (any unused one will *
+# * do, F26 is the higher-numbered one). The change ought to be built *
+# * into the kernel tables. *
+# * *
+# ***************************************************************************
+#
+# The 1.3.x kernels add color-change capabilities; if yours doesn't have this
+# and it matters, turn off <ccc>. The %02x escape used to implement this is
+# not back-portable to SV curses and not supported in ncurses versions before
+# 1.9.9. All linux kernels since 1.2.13 (at least) set the screen size
+# themselves; this entry assumes that capability.
+#
+# The 2.2.x kernels add a private mode that sets the cursor type; use that to
+# get a block cursor for cvvis.
+# reported by Frank Heckenbach <frank@g-n-u.de>.
+linux|linux console,
+ am, bce, eo, mir, msgr, xenl, xon,
+ it#8, ncv#2,
+ acsc=+\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,
+ bel=^G, civis=\E[?25l\E[?1c, clear=\E[H\E[J,
+ cnorm=\E[?25h\E[?0c, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=^J, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A, cvvis=\E[?25h\E[?8c, dch=\E[%p1%dP, dch1=\E[P,
+ dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J,
+ el=\E[K, el1=\E[1K, flash=\E[?5h\E[?5l$<200/>, home=\E[H,
+ hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, kb2=\E[G, kbs=\177,
+ kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kend=\E[4~, kf1=\E[[A, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
+ kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
+ kf19=\E[33~, kf2=\E[[B, kf20=\E[34~, kf3=\E[[C, kf4=\E[[D,
+ kf5=\E[[E, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
+ khome=\E[1~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~, kspd=^Z,
+ nel=^M^J, rc=\E8, rev=\E[7m, ri=\EM, rmir=\E[4l, rmso=\E[27m,
+ rmul=\E[24m, rs1=\Ec\E]R, sc=\E7,
+ sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m,
+ smir=\E[4h, smul=\E[4m, tbc=\E[3g, u6=\E[%i%d;%dR,
+ u7=\E[6n, u8=\E[?6c, u9=\E[c, vpa=\E[%i%p1%dd,
+ use=klone+sgr, use=ecma+color,
+linux-m|Linux console no color,
+ colors@, pairs@,
+ setab@, setaf@, setb@, setf@, use=linux,
+linux-c-nc|linux console 1.3.x hack for ncurses only,
+ ccc,
+ initc=\E]P%p1%x%p2%{255}%*%{1000}%/%02x%p3%{255}%*%{1000}%/%02x%p4%{255}%*%{1000}%/%02x,
+ oc=\E]R,
+ use=linux,
+# From: Dennis Henriksen <opus@osrl.dk>, 9 July 1996
+linux-c|linux console 1.3.6+ with private palette for each virtual console,
+ ccc,
+ colors#8, pairs#64,
+ initc=\E]P%?%p1%{9}%>%t%p1%{10}%-%'a'%+%c%e%p1%d%;%p2%{255}%&%Pr%gr%{16}%/%Px%?%gx%{9}%>%t%gx%{10}%-%'A'%+%c%e%gx%d%;%gr%{15}%&%Px%?%gx%{9}%>%t%gx%{10}%-%'A'%+%c%e%gx%d%;%p3%{255}%&%Pr%gr%{16}%/%Px%?%gx%{9}%>%t%gx%{10}%-%'A'%+%c%e%gx%d%;%gr%{15}%&%Px%?%gx%{9}%>%t%gx%{10}%-%'A'%+%c%e%gx%d%;%p4%{255}%&%Pr%gr%{16}%/%Px%?%gx%{9}%>%t%gx%{10}%-%'A'%+%c%e%gx%d%;%gr%{15}%&%Px%?%gx%{9}%>%t%gx%{10}%-%'A'%+%c%e%gx%d%;,
+ oc=\E]R,
+ use=linux,
+
+# See the note on ICH/ICH1 VERSUS RMIR/SMIR near the end of file
+linux-nic|linux with ich/ich1 suppressed for non-curses programs,
+ ich@, ich1@,
+ use=linux,
+
+# This assumes you have used setfont(8) to load one of the Linux koi8-r fonts.
+# acsc entry from Pavel Roskin" <pavel@absolute.spb.su>, 29 Sep 1997.
+linux-koi8|linux with koi8 alternate character set,
+ acsc=+\020\,\021-\030.^Y0\215`\004a\221f\234g\237h\220i\276j\205k\203l\202m\204n\212o~p\0q\0r\0s_t\206u\207v\211w\210x\201y\230z\231{\267|\274~\224,
+ use=linux, use=klone+koi8acs,
+
+# Another entry for KOI8-r with Qing Long's acsc.
+# (which one better complies with the standard?)
+linux-koi8r|linux with koi8-r alternate character set,
+ kbs=^H, kcub1=^H, kcud1=^J,
+ use=linux, use=klone+koi8acs,
+
+# From: Matthew Vernon <mcv21@pick.sel.cam.ac.uk>
+mach|Mach Console,
+ am, km,
+ cols#80, it#8, lines#25,
+ bel=^G, blink=\E[5m, bold=\E[1m, clear=\Ec, cr=^M,
+ cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
+ cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu=\E[%p1%dA, cuu1=\E[A, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, home=\E[H, ht=^I, il=\E[%p1%dL, il1=\E[L, ind=^J,
+ kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[9, kend=\E[Y, kf1=\EOP, kf10=\EOY, kf2=\EOQ,
+ kf3=\EOR, kf4=\EOS, kf5=\EOT, kf6=\EOU, kf7=\EOV, kf8=\EOW,
+ kf9=\EOX, khome=\E[H, kich1=\E[@, kll=\E[F, knp=\E[U,
+ kpp=\E[V, nel=^M^J, rev=\E[7m, rmso=\E[0m, sgr0=\E[0m,
+ smso=\E[7m,
+mach-bold|Mach Console with bold instead of underline,
+ rmul=\E[0m, smul=\E[1m,
+ use=mach,
+
+# Entry for the latin1 and latin2 fonts
+linux-lat|linux with latin1 or latin2 alternate character set,
+ acsc=+\020\,\021-\030.^Y0\333`\004a\013f\370g\361h\260i\316j\211k\214l\206m\203n\305o~p\304q\212r\304s_t\207u\215v\301w\302x\205y\363z\362{\343|\330}\234~\376,
+ use=linux,
+
+# SCO console and SOS-Syscons console for 386bsd
+# (scoansi: had unknown capabilities
+# :Gc=N:Gd=K:Gh=M:Gl=L:Gu=J:Gv=\072:\
+# :GC=E:GD=B:GH=D:GL=\64:GU=A:GV=\63:GR=C:
+# :G1=?:G2=Z:G3=@:G4=Y:G5=;:G6=I:G7=H:G8=<:\
+# :CW=\E[M:NU=\E[N:RF=\E[O:RC=\E[P:\
+# :WL=\E[S:WR=\E[T:CL=\E[U:CR=\E[V:\
+# I renamed GS/GE/HM/EN/PU/PD/RT and added klone+sgr-dumb, based
+# on the <smacs>=\E[12m -- esr)
+#
+# In this description based on SCO's keyboard(HW) manpage list of default function key
+# values:
+# F13-F24 are shifted F1-F12
+# F25-F36 are control F1-F12
+# F37-F48 are shift+control F1-F12
+scoansi|SCO Extended ANSI standard crt,
+ am, eo, xon,
+ cols#80, it#8, lines#25,
+ blink=\E[5m, bold=\E[1m, cbt=\E[Z, clear=\E[H\E[2J,
+ cub1=\E[D, cud1=\E[B, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A, dch1=\E[P, dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H,
+ ht=^I, ich1=\E[@, il1=\E[L, ind=\E[S, kbs=^H, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kend=\E[F, kf1=\E[M,
+ kf10=\E[V, kf12=\E[W, kf13=\E[Y, kf14=\E[Z, kf15=\E[a,
+ kf16=\E[b, kf17=\E[c, kf18=\E[d, kf19=\E[e, kf2=\E[N,
+ kf20=\E[f, kf21=\E[g, kf22=\E[h, kf23=\E[i, kf24=\E[j,
+ kf25=\E[k, kf26=\E[l, kf27=\E[m, kf28=\E[n, kf29=\E[o,
+ kf3=\E[O, kf30=\E[p, kf31=\E[q, kf32=\E[r, kf33=\E[s,
+ kf34=\E[t, kf35=\E[u, kf36=\E[v, kf37=\E[w, kf38=\E[x,
+ kf39=\E[y, kf4=\E[P, kf40=\E[z, kf41=\E[@, kf42=\E[[,
+ kf43=\E[\\, kf44=\E[], kf45=\E[\014kf46=\E[_, kf47=\E[`,
+ kf48=\E[{, kf5=\E[Q, kf6=\E[R, kf7=\E[S, kf8=\E[T, kf9=\E[U,
+ khome=\E[H, kich1=\E[L, knp=\E[G, kpp=\E[I, krdo=\E[F,
+ ri=\E[T,
+ use=klone+sgr-dumb,
+
+# This actually describes the generic SVr4 display driver for Intel boxes.
+# The <dim=\E[2m> isn't documented and therefore may not be reliable.
+# From: Eric Raymond <esr@snark.thyrsus.com> Mon Nov 27 19:00:53 EST 1995
+att6386|at386|386at|AT&T WGS 6386 console,
+ am, bw, eo, xon,
+ cols#80, it#8, lines#25,
+ acsc=``a1fxgqh0jYk?lZm@nEooppqDrrsstCu4vAwBx3yyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[=C,
+ clear=\E[2J\E[H, cnorm=\E[=1C, cr=^M, cub=\E[%p1%dD,
+ cub1=\E[D, cud=\E[%p1%dB, cud1=\E[B, cuf=\E[%p1%dC,
+ cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA,
+ cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
+ dl=\E[%p1%dM, dl1=\E[1M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
+ home=\E[H, hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
+ ich1=\E[1@, il=\E[%p1%dL, il1=\E[1L, ind=\E[S,
+ indn=\E[%p1%dS, invis=\E[9m, is2=\E[0;10;39m, kbs=^H,
+ kcbt=^], kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[P, kend=\E[Y, kf1=\EOP, kf10=\EOY, kf11=\EOZ,
+ kf12=\EOA, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOT, kf6=\EOU,
+ kf7=\EOV, kf8=\EOW, kf9=\EOX, khome=\E[H, kich1=\E[@,
+ knp=\E[U, kpp=\E[V, krmir=\E0, nel=\r\E[S, rc=\E8, rev=\E[7m,
+ ri=\E[T, rin=\E[%p1%dT, rmacs=\E[10m, rmso=\E[m, rmul=\E[m,
+ sc=\E7,
+ sgr=\E[10m\E[0%?%p1%p3%|%t;7%;%?%p2%t;4%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p9%t;12%e;10%;%?%p7%t;9%;m,
+ sgr0=\E[0;10m, smacs=\E[12m, smso=\E[7m, smul=\E[4m,
+ tbc=\E[2g, vpa=\E[%i%p1%dd,
+ use=klone+color,
+# (pc6300plus: removed ":KM=/usr/lib/ua/kmap.s5:"; renamed BO/EE/CI/CV -- esr)
+pc6300plus|AT&T 6300 plus,
+ am, xon,
+ cols#80, lines#24,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[=C,
+ clear=\E[2J\E[H, cnorm=\E[=1C, cr=^M, cub1=^H, cud1=\E[B,
+ cuf1=\E[C, cup=\E[%i%p1%2d;%p2%2dH, cuu1=\E[A,
+ dch1=\E[1P, dim=\E[2m, dl1=\E[1M, ed=\E[0J, el=\E[0K,
+ home=\E[H, hts=\EH, ich1=\E[1@, il1=\E[1L, ind=^J,
+ invis=\E[9m, kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
+ kcuu1=\E[A, kf1=\EOc, kf10=\EOu, kf2=\EOd, kf3=\EOe,
+ kf4=\EOf, kf5=\EOg, kf6=\EOh, kf7=\EOi, kf8=\EOj, kf9=\EOk,
+ nel=^M^J, rev=\E[7m, rmso=\E[m, rmul=\E[m, sgr0=\E[m,
+ smso=\E[7m, smul=\E[4m, tbc=\E[3g,
+
+# From: Benjamin C. W. Sittler <bsittler@nmt.edu>
+#
+# I have a UNIX PC which I use as a terminal attached to my Linux PC.
+# Unfortunately, the UNIX PC terminfo entry that comes with ncurses
+# is broken. All the special key sequences are broken, making it unusable
+# with Emacs. The problem stems from the following:
+#
+# The UNIX PC has a plethora of keys (103 of them, and there's no numeric
+# keypad!), loadable fonts, and strange highlighting modes ("dithered"
+# half-intensity, "smeared" bold, and real strike-out, for example.) It also
+# uses resizable terminal windows, but the bundled terminal program always
+# uses an 80x24 window (and doesn't support seem to support a 132-column
+# mode.)
+#
+# HISTORY: The UNIX PC was one of the first machines with a GUI, and used a
+# library which was a superset of SVr3.5 curses (called tam, for "terminal
+# access method".) tam includes support for real, overlapping windows,
+# onscreen function key labels, and bitmap graphics. But since the primary
+# user interface on the UNIX PC was a GUI program (ua, for "user
+# assistant",) and remote administration was considered important for the
+# machine, tam also supported VT100-compatible terminals attached to the
+# serial port or used across the StarLan network. To simulate the extra keys
+# not present on a VT100, users could press ESC and a two-letter sequence,
+# such as u d (Undo) or U D (Shift-Undo.) These two-letter sequences,
+# however, were not the same as those sent by the actual Undo key. The
+# actual Undo key sends ESC 0 s unshifted, and ESC 0 S shifted, for example.
+# (If you're interested in adding some of the tam calls to ncurses, btw, I
+# have the full documentation and several programs which use tam. It also
+# used an extended terminfo format to describe key sequences, special
+# highlighting modes, etc.)
+#
+# KEYS: This means that ncurses would quite painful on the UNIX PC, since
+# there are two sequences for every key-modifier combination (local keyboard
+# sequence and remote "VT100" sequence.) But I doubt many people are trying
+# to use ncurses on the UNIX PC, since ncurses doesn't properly handle the
+# GUI. Unfortunately, the terminfo entry (and the termcap, too, I presume)
+# seem to have been built from the manual describing the VT100 sequences.
+# This means it doesn't work for a real live UNIX PC.
+#
+# FONTS: The UNIX PC also has a strange interpretation of "alternate
+# character set". Rather than the VT100 graphics you might expect, it allows
+# up to 8 custom fonts to be loaded at any given time. This means that
+# programs expecting VT100 graphics will usually be disappointed. For this
+# reason I have disabled the smacs/rmacs sequences, but they could easily be
+# re-enabled. Here are the relevant control sequences (from the ESCAPE(7)
+# manpage), should you wish to do so:
+#
+# SGR10 - Select font 0 - ESC [ 10 m or SO
+# SGR11 - Select font 1 - ESC [ 11 m or SI
+# SGR12 - Select font 2 - ESC [ 12 m
+# ... (etc.)
+# SGR17 - Select font 7 - ESC [ 17 m
+#
+# Graphics for line drawing are not reliably found at *any* character
+# location because the UNIX PC has dynamically reloadable fonts. I use font
+# 0 for regular text and font 1 for italics, but this is by no means
+# universal. So ASCII line drawing is in order if smacs/rmacs are enabled.
+#
+# MISC: The cursor visible/cursor invisible sequences were swapped in the
+# distributed terminfo.
+#
+# To ameliorate these problems (and fix a few highlighting bugs) I rewrote
+# the UNIX PC terminfo entry. The modified version works great with Lynx,
+# Emacs, and XEmacs running on my Linux PC and displaying on the UNIX PC
+# attached by serial cable. In Emacs, even the Undo key works, and many
+# applications can now use the F1-F8 keys.
+#
+# esr's notes:
+# Terminfo entry for the AT&T Unix PC 7300
+# from escape(7) in Unix PC 7300 Manual.
+# Somewhat similar to a vt100-am (but different enough
+# to redo this from scratch.)
+#
+# /***************************************************************
+# *
+# * FONT LOADING PROGRAM FOR THE UNIX PC
+# *
+# * This routine loads a font defined in the file ALTFONT
+# * into font memory slot #1. Once the font has been loaded,
+# * it can be used as an alternative character set.
+# *
+# * The call to ioctl with the argument WIOCLFONT is the key
+# * to this routine. For more information, see window(7) in
+# * the PC 7300 documentation.
+# ***************************************************************/
+# #include <string.h> /* needed for strcpy call */
+# #include <sys/window.h> /* needed for ioctl call */
+# #define FNSIZE 60 /* font name size */
+# #define ALTFONT "/usr/lib/wfont/special.8.ft" /* font file */
+# /*
+# * The file /usr/lib/wfont/special.8.ft comes with the
+# * standard PC software. It defines a graphics character set
+# * similar to that of the Teletype 5425 terminal. To view
+# * this or other fonts in /usr/lib/wfont, use the command
+# * cfont <filename>. For further information on fonts see
+# * cfont(1) in the PC 7300 documentation.
+# */
+#
+# struct altfdata /* structure for alt font data */
+# {
+# short altf_slot; /* memory slot number */
+# char altf_name[FNSIZE]; /* font name (file name) */
+# };
+# ldfont()
+# {
+# int wd; /* window in which altfont will be */
+# struct altfdata altf;
+# altf.altf_slot=1;
+# strcpy(altf.altf_name,ALTFONT);
+# for (wd =1; wd < 12; wd++) {
+# ioctl(wd, WIOCLFONT,&altf);
+# }
+# }
+#
+# (att7300: added <civis>/<cnorm>/<ich1>/<invis> from the BSDI entry,
+# they're confirmed by the man page for the System V display---esr)
+#
+att7300|unixpc|pc7300|3b1|s4|AT&T UNIX PC Model 7300,
+ am, xon,
+ cols#80, it#8, lines#24,
+ bel=^G, blink=\E[9m, bold=\E[1m, cbt=\E^I, civis=\E[=1C,
+ clear=\E[2J\E[H, cnorm=\E[=0C, cr=^M, cub=\E[%p1%dD,
+ cub1=^H, cud=\E[%p1%dB, cud1=\E[B, cuf=\E[%p1%dC,
+ cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA,
+ cuu1=\E[A, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM, dl1=\E[M,
+ ed=\E[0J, el=\E[0K, home=\E[H, ich1=\E[@, il=\E[%p1%dL,
+ il1=\E[L, ind=^J, invis=\E[9m, is1=\017\E[=1w, kBEG=\ENB,
+ kCAN=\EOW, kCPY=\END, kCRT=\EON, kDC=\ENF, kDL=\ENE,
+ kEND=\ENN, kEOL=\EOA, kFND=\EOX, kHLP=\EOM, kHOM=\ENM,
+ kIC=\ENJ, kLFT=\ENK, kMOV=\ENC, kNXT=\ENH, kOPT=\EOR,
+ kPRV=\ENG, kRDO=\EOT, kRIT=\ENL, kRPL=\EOY, kSAV=\EOO,
+ kUND=\EOS, kbeg=\ENb, kbs=^H, kcan=\EOw, kcbt=\E[Z,
+ kclo=\EOV, kclr=\E[J, kcmd=\EOu, kcpy=\ENd, kcrt=\EOn,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=\ENf,
+ ked=\E[J, kel=\EOa, kend=\E0, kext=\EOk, kf1=\EOc, kf2=\EOd,
+ kf3=\EOe, kf4=\EOf, kf5=\EOg, kf6=\EOh, kf7=\EOi, kf8=\EOj,
+ kfnd=\EOx, khlp=\EOm, khome=\E[H, kich1=\ENj, kind=\E[B,
+ kmov=\ENc, kmrk=\ENi, knp=\E[U, knxt=\ENh, kopn=\EOv,
+ kopt=\EOr, kpp=\E[V, kprt=\EOz, kprv=\ENg, krdo=\EOt,
+ kref=\EOb, krfr=\ENa, kri=\E[A, krpl=\EOy, krst=\EOB,
+ ksav=\EOo, kslt=\ENI, kund=\EOs, nel=\EE, rev=\E[7m, ri=\EM,
+ rmso=\E[m, rmul=\E[m, sgr0=\E[0;10m, smso=\E[7m,
+ smul=\E[4m,
+
+# Sent by Stefan Stapelberg <stefan@rent-a-guru.de>, 24 Feb 1997, this is
+# from SGI's terminfo database. SGI's entry shows F9-F12 with the codes
+# for the application keypad mode. We have added iris-ansi-ap rather than
+# change the original to keypad mode.
+#
+# (iris-ansi: added rmam/smam based on init string -- esr)
+#
+# This entry, and those derived from it, is used in xwsh (also known as
+# winterm). Some capabilities that do not fit into the terminfo model
+# include the shift- and control-functionkeys:
+#
+# F1-F12 generate different codes when shift or control modifiers are used.
+# For example:
+# F1 \E[001q
+# shift F1 \E[013q
+# control-F1 \E[025q
+#
+# In application keypad mode, F9-F12 generate codes like vt100 PF1-PF4, i.e.,
+# \EOP to \EOS. The shifted and control modifiers still do the same thing.
+#
+# The cursor keys also have different codes:
+# control-up \E[162q
+# control-down \E[165q
+# control-left \E[159q
+# control-right \E[168q
+#
+# shift-up \E[161q
+# shift-down \E[164q
+# shift-left \E[158q
+# shift-right \E[167q
+#
+# control-tab \[072q
+#
+iris-ansi|IRIS emulating 40 line ANSI terminal (almost VT100),
+ am,
+ cols#80, it#8, lines#40,
+ bel=^G, bold=\E[1m, clear=\E[H\E[2J,
+ cnorm=\E[9/y\E[12/y\E[=6l, cr=^M, cub=\E[%p1%dD,
+ cub1=\E[D, cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC,
+ cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA,
+ cuu1=\E[A, cvvis=\E[10/y\E[=1h\E[=2l\E[=6h,
+ dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K,
+ home=\E[H, ht=^I, hts=\EH, il=\E[%p1%dL, il1=\E[L, ind=\ED,
+ is2=\E[?1l\E>\E[?7h\E[100g\E[0m\E7\E[r\E8, kDC=\E[P,
+ kEND=\E[147q, kHOM=\E[143q, kLFT=\E[158q, kPRT=\E[210q,
+ kRIT=\E[167q, kSPD=\E[218q, kbs=^H, kcbt=\E[Z, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=\177,
+ kend=\E[146q, kent=^M, kf1=\E[001q, kf10=\E[010q,
+ kf11=\E[011q, kf12=\E[012q, kf2=\E[002q, kf3=\E[003q,
+ kf4=\E[004q, kf5=\E[005q, kf6=\E[006q, kf7=\E[007q,
+ kf8=\E[008q, kf9=\E[009q, khome=\E[H, kich1=\E[139q,
+ knp=\E[154q, kpp=\E[150q, kprt=\E[209q, krmir=\E[146q,
+ kspd=\E[217q, nel=\EE, pfkey=\EP101;%p1%d.y%p2%s\E\\,
+ rc=\E8, rev=\E[7m, ri=\EM, rmam=\E[?7l, rmso=\E[m, rmul=\E[m,
+ sc=\E7, sgr0=\E[m, smam=\E[?7h, smso=\E[1;7m, smul=\E[4m,
+ tbc=\E[3g,
+iris-ansi-ap|IRIS ANSI in application-keypad mode,
+ is2=\E[?1l\E=\E[?7h, kent=\EOM, kf10=\E[010q,
+ kf11=\E[011q, kf12=\E[012q, kf9=\E[009q,
+ use=iris-ansi,
+
+# From the man-page, this is a quasi-vt100 emulator that runs on SGI's IRIX
+# (T.Dickey 98/1/24)
+iris-color|xwsh|IRIX ANSI with color,
+ ncv#33,
+ csr=\E[%i%p1%d;%p2%dr, dch=\E[%p1%dP, dim=\E[2m,
+ ech=\E[%p1%dX, ich=\E[%p1%d@, rc=\E8, ritm=\E[23m,
+ rmul=\E[24m, rs1=\Ec,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
+ sitm=\E[3m, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,
+ use=klone+color, use=iris-ansi-ap,
+
+# The following is a version of the ibm-pc entry distributed with PC/IX,
+# (Interactive Systems' System 3 for the Big Blue), modified by Richard
+# McIntosh at UCB/CSM. The :pt: and :uc: have been removed from the original,
+# (the former is untrue, and the latter failed under UCB/man); standout and
+# underline modes have been added. Note: this entry describes the "native"
+# capabilities of the PC monochrome display, without ANY emulation; most
+# communications packages (but NOT PC/IX connect) do some kind of emulation.
+pcix|PC/IX console,
+ am, bw, eo,
+ cols#80, lines#24,
+ clear=\Ec, cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%2d;%p2%2dH, cuu1=\E[A, ed=\E[J, el=\E[K,
+ home=\E[H, rmso=\E[m, rmul=\E[m, sgr0=\E[m, smso=\E[7m,
+ smul=\E[4m,
+
+# (ibmpcx: this entry used to be known as ibmx.
+# It formerly included the following extension capabilities:
+# :GC=b:GL=v:GR=t:RT=^J:\
+# :GH=\E[196g:GV=\E[179g:\
+# :GU=\E[193g:GD=\E[194g:\
+# :G1=\E[191g:G2=\E[218g:G3=\E[192g:G4=\E[217g:\
+# :CW=\E[E:NU=\E[F:RF=\E[G:RC=\E[H:\
+# :WL=\E[K:WR=\E[L:CL=\E[M:CR=\E[N:\
+# I renamed GS/GE/WL/WR/CL/CR/PU/PD/HM/EN; also, removed a duplicate
+# ":kh=\E[Y:". Added IBM-PC forms characters and highlights, they match
+# what was there before. -- esr)
+ibmpcx|xenix|ibmx|IBM PC xenix console display,
+ am, msgr,
+ cols#80, lines#25,
+ clear=^L, cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%p1%d;%p2%dH, cuu1=\E[A, dch1=\E[P, dl1=\E[M,
+ ed=\E[J, el=\E[K, home=\E[H, ich1=\E[@, il1=\E[L, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kend=\E[d,
+ kf1=\E[K, kf2=\E[L, kf3=\E[M, kf4=\E[N, khome=\E[Y, knp=\E[e,
+ kpp=\E[Z,
+ use=klone+acs, use=klone+sgr,
+
+
+# QNX 4.0 Console
+# Michael's original version of this entry had <am@>, <smcup=\Ei>,
+# <rmcup=\Eh\ER>; this was so terminfo applications could write the lower
+# right corner without triggering a scroll. The ncurses terminfo library can
+# handle this case with the <ich1> capability, and prefers <am> for better
+# optimization. Bug: The <op> capability resets attributes.
+# From: Michael Hunter <mphunter@qnx.com> 30 Jul 1996
+# (removed: <sgr=%?%p1%t\E<%;%p2%t\E[%;%p3%t\E(%;%p4%t\E{%;%p6%t\E<%;,>)
+qnx|qnx4|qnx console,
+ daisy, km, mir, msgr, xhpa, xt,
+ colors#8, cols#80, it#4, lines#25, ncv#3, pairs#8,
+ acsc=O\333a\261j\331k\277l\332m\300n\305o\337q\304s\334t\303u\264v\301w\302x\263,
+ bel=^G, blink=\E{, bold=\E<, civis=\Ey0, clear=\EH\EJ,
+ cnorm=\Ey1, cr=^M, cub1=^H, cud1=^J, cuf1=\EC,
+ cup=\EY%p1%{32}%+%c%p2%{32}%+%c, cuu1=\EA, cvvis=\Ey2,
+ dch1=\Ef, dl1=\EF, ed=\EJ, el=\EK, home=\EH, ht=^I, ich1=\Ee,
+ il1=\EE, ind=^J, kBEG=\377\356, kCAN=\377\263,
+ kCMD=\377\267, kCPY=\377\363, kCRT=\377\364,
+ kDL=\377\366, kEND=\377\301, kEOL=\377\311,
+ kEXT=\377\367, kFND=\377\370, kHLP=\377\371,
+ kHOM=\377\260, kIC=\377\340, kLFT=\377\264,
+ kMOV=\377\306, kMSG=\377\304, kNXT=\377\272,
+ kOPT=\377\372, kPRT=\377\275, kPRV=\377\262,
+ kRDO=\377\315, kRES=\377\374, kRIT=\377\266,
+ kRPL=\377\373, kSAV=\377\307, kSPD=\377\303,
+ kUND=\377\337, kbeg=\377\300, kcan=\377\243, kcbt=\377\0,
+ kclo=\377\343, kclr=\377\341, kcmd=\377\245,
+ kcpy=\377\265, kcrt=\377\305, kctab=\377\237,
+ kcub1=\377\244, kcud1=\377\251, kcuf1=\377\246,
+ kcuu1=\377\241, kdch1=\377\254, kdl1=\377\274,
+ ked=\377\314, kel=\377\310, kend=\377\250, kent=\377\320,
+ kext=\377\270, kf1=\377\201, kf10=\377\212,
+ kf11=\377\256, kf12=\377\257, kf13=\377\213,
+ kf14=\377\214, kf15=\377\215, kf16=\377\216,
+ kf17=\377\217, kf18=\377\220, kf19=\377\221,
+ kf2=\377\202, kf20=\377\222, kf21=\377\223,
+ kf22=\377\224, kf23=\377\333, kf24=\377\334,
+ kf25=\377\225, kf26=\377\226, kf27=\377\227,
+ kf28=\377\230, kf29=\377\231, kf3=\377\203,
+ kf30=\377\232, kf31=\377\233, kf32=\377\234,
+ kf33=\377\235, kf34=\377\236, kf35=\377\276,
+ kf36=\377\277, kf37=\377\321, kf38=\377\322,
+ kf39=\377\323, kf4=\377\204, kf40=\377\324,
+ kf41=\377\325, kf42=\377\326, kf43=\377\327,
+ kf44=\377\330, kf45=\377\331, kf46=\377\332,
+ kf47=\377\316, kf48=\377\317, kf5=\377\205, kf6=\377\206,
+ kf7=\377\207, kf8=\377\210, kf9=\377\211, kfnd=\377\346,
+ khlp=\377\350, khome=\377\240, khts=\377\342,
+ kich1=\377\253, kil1=\377\273, kind=\377\261,
+ kmov=\377\351, kmrk=\377\355, kmsg=\377\345,
+ knp=\377\252, knxt=\377\312, kopn=\377\357,
+ kopt=\377\353, kpp=\377\242, kprt=\377\255,
+ kprv=\377\302, krdo=\377\336, kref=\377\354,
+ kres=\377\360, krfr=\377\347, kri=\377\271,
+ krmir=\377\313, krpl=\377\362, krst=\377\352,
+ ksav=\377\361, kslt=\377\247, kspd=\377\335,
+ ktbc=\377\344, kund=\377\365, mvpa=\E!%p1%02d, op=\ER,
+ rep=\Eg%p2%{32}%+%c%p1%c, rev=\E(, ri=\EI, rmcup=\Eh\ER,
+ rmso=\E), rmul=\E], rs1=\ER, setb=\E@%p1%Pb%gb%gf%d%d,
+ setf=\E@%p1%Pf%gb%gf%d%d, sgr0=\E}\E]\E>\E), smcup=\Ei,
+ smso=\E(, smul=\E[,
+
+# From: Federico Bianchi <bianchi@pc-arte2.arte.unipi.it>, 1 Jul 1998
+# (esr: commented out <scp> and <rmcup> to avoid warnings.)
+# (TD: derive from original qnx4 entry)
+qnxt2|qnx 2.15 serial terminal,
+ am,
+ civis@, cnorm@, cvvis@, dch1@, ich1@, kRES@, kRPL@, kUND@, kspd@,
+ rep@, rmcup@, rmso=\E>, setb@, setf@, smcup@, smso=\E<,
+ use=qnx4,
+
+#### NetBSD consoles
+#
+# pcvt termcap database entries (corresponding to release 3.31)
+# Author's last edit-date: [Fri Sep 15 20:29:10 1995]
+#
+# (For the terminfo master file, I translated these into terminfo syntax.
+# Then I dropped all the pseudo-HP entries. we don't want and can't use
+# the :Xs: flag. Then I split :is: into a size-independent <is1> and a
+# size-dependent <is2>. Finally, I added <rmam>/<smam> -- esr)
+
+# NOTE: <ich1> has been taken out of this entry. for reference, it should
+# be <ich1=\E[@>. For discussion, see ICH/ICH1 VERSUS RMIR/SMIR below.
+# (esr: added <civis> and <cnorm> to resolve NetBSD Problem Report #4583)
+pcvtXX|pcvt vt200 emulator (DEC VT220),
+ am, km, mir, msgr, xenl,
+ it#8, vt#3,
+ acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[J, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=\E[B, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, el1=\E[1K, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
+ il=\E[%p1%dL, il1=\E[L, ind=\ED, indn=\E[%p1%dS,
+ is1=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, kbs=\177,
+ kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kdch1=\E[3~, kf1=\E[17~, kf2=\E[18~, kf3=\E[19~,
+ kf4=\E[20~, kf5=\E[21~, kf6=\E[23~, kf7=\E[24~, kf8=\E[25~,
+ khome=\E[1~, kich1=\E[2~, kll=\E[4~, knp=\E[6~, kpp=\E[5~,
+ nel=\EE, rc=\E8, rev=\E[7m, rf=/usr/share/tabset/vt100,
+ ri=\EM, rin=\E[%p1%dT, rmacs=\E(B, rmam=\E[?7l, rmir=\E[4l,
+ rmkx=\E[?1l\E>, rmso=\E[27m, rmul=\E[24m,
+ rs1=\Ec\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
+ sgr0=\E[m, smacs=\E(0, smam=\E[?7h, smir=\E[4h,
+ smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
+
+# NetBSD/FreeBSD vt220 terminal emulator console (pc keyboard & monitor)
+# termcap entries for pure VT220-Emulation and 25, 28, 35, 40, 43 and
+# 50 lines entries; 80 columns
+pcvt25|dec vt220 emulation with 25 lines,
+ cols#80, lines#25,
+ is2=\E[1;25r\E[25;1H, use=pcvtXX,
+pcvt28|dec vt220 emulation with 28 lines,
+ cols#80, lines#28,
+ is2=\E[1;28r\E[28;1H, use=pcvtXX,
+pcvt35|dec vt220 emulation with 35 lines,
+ cols#80, lines#35,
+ is2=\E[1;35r\E[35;1H, use=pcvtXX,
+pcvt40|dec vt220 emulation with 40 lines,
+ cols#80, lines#40,
+ is2=\E[1;40r\E[40;1H, use=pcvtXX,
+pcvt43|dec vt220 emulation with 43 lines,
+ cols#80, lines#43,
+ is2=\E[1;43r\E[43;1H, use=pcvtXX,
+pcvt50|dec vt220 emulation with 50 lines,
+ cols#80, lines#50,
+ is2=\E[1;50r\E[50;1H, use=pcvtXX,
+
+# NetBSD/FreeBSD vt220 terminal emulator console (pc keyboard & monitor)
+# termcap entries for pure VT220-Emulation and 25, 28, 35, 40, 43 and
+# 50 lines entries; 132 columns
+pcvt25w|dec vt220 emulation with 25 lines and 132 cols,
+ cols#132, lines#25,
+ is2=\E[1;25r\E[25;1H, use=pcvtXX,
+pcvt28w|dec vt220 emulation with 28 lines and 132 cols,
+ cols#132, lines#28,
+ is2=\E[1;28r\E[28;1H, use=pcvtXX,
+pcvt35w|dec vt220 emulation with 35 lines and 132 cols,
+ cols#132, lines#35,
+ is2=\E[1;35r\E[35;1H, use=pcvtXX,
+pcvt40w|dec vt220 emulation with 40 lines and 132 cols,
+ cols#132, lines#40,
+ is2=\E[1;40r\E[40;1H, use=pcvtXX,
+pcvt43w|dec vt220 emulation with 43 lines and 132 cols,
+ cols#132, lines#43,
+ is2=\E[1;43r\E[43;1H, use=pcvtXX,
+pcvt50w|dec vt220 emulation with 50 lines and 132 cols,
+ cols#132, lines#50,
+ is2=\E[1;50r\E[50;1H, use=pcvtXX,
+
+# Terminfo entries to enable the use of the ncurses library in colour on a
+# NetBSD-arm32 console (only tested on a RiscPC).
+# Created by Dave Millen <dmill@globalnet.co.uk> 22.07.98
+# modified codes for setf/setb to setaf/setab, then to klone+color, corrected
+# typo in invis - TD
+arm100|arm100-am|Arm(RiscPC) ncurses compatible (for 640x480),
+ am, bce, msgr, xenl, xon,
+ cols#80, it#8, lines#30,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
+ 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=^J,
+ invis=\E[8m$<2>, ka1=\E[q, ka3=\E[s, kb2=\E[r, kbs=^H,
+ kc1=\E[p, kc3=\E[n, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
+ kcuu1=\E[A, kent=\E[M, kf0=\E[y, kf1=\E[P, kf10=\E[x,
+ kf2=\E[Q, kf3=\E[R, kf4=\E[S, kf5=\E[t, kf6=\E[u, kf7=\E[v,
+ kf8=\E[l, kf9=\E[w, rc=\E8, rev=\E[6m$<2>, ri=\EM$<5>,
+ rmacs=^O, rmam=\E[?7l, rmkx=\E[?1l\E>, rmso=\E[m$<2>,
+ rmul=\E[m$<2>, rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
+ 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%;,
+ sgr0=\E[m\017$<2>, smacs=^N, smam=\E[?7h, smkx=\E[?1h\E=,
+ smso=\E[7m$<2>, smul=\E[4m$<2>, tbc=\E[3g,
+ use=ecma+sgr, use=klone+color,
+
+arm100-w|arm100-wam|Arm(RiscPC) ncurses compatible (for 1024x768),
+ cols#132, lines#50, use=arm100,
+
+# NetBSD/x68k console vt200 emulator. This port runs on a 68K machine
+# manufactured by Sharp for the Japenese market.
+# From Minoura Makoto <minoura@netlaputa.or.jp>, 12 May 1996
+x68k|x68k-ite|NetBSD/x68k ITE,
+ cols#96, lines#32,
+ kclr=\E[9~, khlp=\E[28~, use=vt220,
+
+#### FreeBSD console entries
+#
+# From: Andrey Chernov <ache@astral.msk.su> 29 Mar 1996
+# Andrey Chernov maintains the FreeBSD termcap distributions.
+#
+# Note: Users of FreeBSD 2.1.0 and older versions must either upgrade
+# or comment out the :cb: capability in the console entry.
+#
+# Alexander Lukyanov reports:
+# I have seen FreeBSD-2.1.5R... The old el1 bug changed, but it is still there.
+# Now el1 clears not only to the line beginning, but also a large chunk
+# of previous line. But there is another bug - ech does not work at all.
+#
+
+# for syscons
+# common entry without semigraphics
+# Bug: The <op> capability resets attributes.
+# Bug? The ech and el1 attributes appear to move the cursor in some cases; for
+# instance el1 does if the cursor is moved to the right margin first. Removed
+# by T.Dickey 97/5/3 (ech=\E[%p1%dX, el1=\E[1K)
+#
+# Setting colors turns off reverse; we cannot guarantee order, so use ncv.
+# Note that this disables standout with color.
+cons25w|ansiw|ansi80x25-raw|freebsd console (25-line raw mode),
+ am, bce, bw, eo, msgr, npc,
+ colors#8, cols#80, it#8, lines#25, ncv#5, pairs#64,
+ bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, clear=\E[H\E[J,
+ cr=^M, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=\E[B,
+ cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu=\E[%p1%dA, cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P,
+ dim=\E[30;1m, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K,
+ home=\E[H, hpa=\E[%i%p1%d`, ht=^I, ich=\E[%p1%d@,
+ ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=\E[S,
+ indn=\E[%p1%dS, kb2=\E[E, kbs=^H, kcbt=\E[Z, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=\177, kend=\E[F,
+ kf1=\E[M, kf10=\E[V, kf11=\E[W, kf12=\E[X, kf2=\E[N,
+ kf3=\E[O, kf4=\E[P, kf5=\E[Q, kf6=\E[R, kf7=\E[S, kf8=\E[T,
+ kf9=\E[U, khome=\E[H, kich1=\E[L, knp=\E[G, kpp=\E[I,
+ nel=\E[E, op=\E[x, rev=\E[7m, ri=\E[T, rin=\E[%p1%dT,
+ rmso=\E[m, rs1=\E[x\E[m\Ec, setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm, sgr0=\E[m, smso=\E[7m, vpa=\E[%i%p1%dd,
+cons25|ansis|ansi80x25|freebsd console (25-line ansi mode),
+ acsc=-\030.^Y0\333`\004a\260f\370g\361h\261i\025j\331k\277l\332m\300n\305q\304t\303u\264v\301w\302x\263y\363z\362~\371,
+ use=cons25w,
+cons25-m|ansis-mono|ansi80x25-mono|freebsd console (25-line mono ansi mode),
+ colors@, pairs@,
+ bold@, dim@, op@, rmul=\E[m, setab@, setaf@, smul=\E[4m, use=cons25,
+cons30|ansi80x30|freebsd console (30-line ansi mode),
+ lines#30, use=cons25,
+cons30-m|ansi80x30-mono|freebsd console (30-line mono ansi mode),
+ lines#30, use=cons25-m,
+cons43|ansi80x43|freebsd console (43-line ansi mode),
+ lines#43, use=cons25,
+cons43-m|ansi80x43-mono|freebsd console (43-line mono ansi mode),
+ lines#43, use=cons25-m,
+cons50|ansil|ansi80x50|freebsd console (50-line ansi mode),
+ lines#50, use=cons25,
+cons50-m|ansil-mono|ansi80x50-mono|freebsd console (50-line mono ansi mode),
+ lines#50, use=cons25-m,
+cons60|ansi80x60|freebsd console (60-line ansi mode),
+ lines#60, use=cons25,
+cons60-m|ansi80x60-mono|freebsd console (60-line mono ansi mode),
+ lines#60, use=cons25-m,
+cons25r|pc3r|ibmpc3r|cons25-koi8-r|freebsd console w/koi8-r cyrillic,
+ acsc=-\030.^Y0\215`\004a\220f\234h\221i\025j\205k\203l\202m\204n\212q\0t\206u\207v\211w\210x\201y\230z\231~\225,
+ use=cons25w,
+cons25r-m|pc3r-m|ibmpc3r-mono|cons25-koi8r-m|freebsd console w/koi8-r cyrillic (mono),
+ colors@, pairs@,
+ op@, rmul=\E[m, setab@, setaf@, smul=\E[4m, use=cons25r,
+cons50r|cons50-koi8r|freebsd console w/koi8-r cyrillic (50 lines),
+ lines#50, use=cons25r,
+cons50r-m|cons50-koi8r-m|freebsd console w/koi8-r cyrillic (50-line mono),
+ lines#50, use=cons25r-m,
+cons60r|cons60-koi8r|freebsd console w/koi8-r cyrillic (60 lines),
+ lines#60, use=cons25r,
+cons60r-m|cons60-koi8r-m|freebsd console w/koi8-r cyrillic (60-line mono),
+ lines#60, use=cons25r-m,
+# ISO 8859-1 FreeBSD console
+cons25l1|cons25-iso8859|freebsd console w/iso 8859-1 chars,
+ acsc=+\253\,\273-\030.\031`\201a\202f\207g\210i\247j\213k\214l\215m\216n\217o\220p\221q\222r\223s\224t\225u\226v\227w\230x\231y\232z\233~\237,
+ use=cons25w,
+cons25l1-m|cons25-iso-m|freebsd console w/iso 8859-1 chars (mono),
+ colors@, pairs@,
+ bold@, dim@, op@, rmul=\E[m, setab@, setaf@, smul=\E[4m, use=cons25l1,
+cons50l1|cons50-iso8859|freebsd console w/iso 8859-1 chars (50 lines),
+ lines#50, use=cons25l1,
+cons50l1-m|cons50-iso-m|freebsd console w/iso 8859-1 chars (50-line mono),
+ lines#50, use=cons25l1-m,
+cons60l1|cons60-iso|freebsd console w/iso 8859-1 chars (60 lines),
+ lines#60, use=cons25l1,
+cons60l1-m|cons60-iso-m|freebsd console w/iso 8859-1 chars (60-line mono),
+ lines#60, use=cons25l1-m,
+
+#### 386BSD and BSD/OS Consoles
+#
+
+# This was the original 386BSD console entry (I think).
+# Some places it's named oldpc3|oldibmpc3.
+# From: Alex R.N. Wetmore <aw2t@andrew.cmu.edu>
+origpc3|origibmpc3|IBM PC 386BSD Console,
+ am, bw, eo, xon,
+ cols#80, lines#25,
+ acsc=j\331k\277l\332m\300n\305q\304t\303u\264v\301w\302x\263,
+ bold=\E[7m, clear=\Ec, cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%2d;%p2%2dH, cuu1=\E[A, ed=\E[J, el=\E[K,
+ home=\E[H, ind=\E[S, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
+ kcuu1=\E[A, khome=\E[Y, ri=\E[T, rmso=\E[1;0x\E[2;7x,
+ rmul=\E[1;0x\E[2;7x, sgr0=\E[m\E[1;0x\E[2;7x,
+ smso=\E[1;7x\E[2;0x, smul=\E[1;7x\E[2;0x,
+
+# description of BSD/386 console emulator in version 1.0 (supplied by BSDI)
+oldpc3|oldibmpc3|old IBM PC BSD/386 Console,
+ km,
+ lines#25,
+ bel=^G, bold=\E[=15F, cr=^M, cud1=^J, dim=\E[=8F, dl1=\E[M,
+ ht=^I, il1=\E[L, ind=^J, kbs=^H, kcub1=\E[D, kcud1=\E[B,
+ kcuf1=\E[C, kcuu1=\E[A, khome=\E[H, kich1=\E[L, kll=\E[F,
+ knp=\E[G, kpp=\E[I, nel=^M^J, sgr0=\E[=R,
+
+# Description of BSD/OS console emulator in version 1.1, 2.0, 2.1
+# Note, the emulator supports many of the additional console features
+# listed in the iBCS2 (e.g. character-set selection) though not all
+# are described here. This entry really ought to be upgraded.
+# Also note, the console will also work with fewer lines after doing
+# "stty rows NN", e.g. to use 24 lines.
+# (Color support from Kevin Rosenberg <kevin@cyberport.com>, 2 May 1996)
+# Bug: The <op> capability resets attributes.
+bsdos-pc-nobold|BSD/OS PC console w/o bold,
+ am, eo, km, xon,
+ cols#80, it#8, lines#25,
+ bel=^G, clear=\Ec, cr=^M, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, ht=^I,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, kbs=^H, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, khome=\E[H, kich1=\E[L,
+ kll=\E[F, knp=\E[G, kpp=\E[I, nel=^M^J, rc=\E8, sc=\E7,
+ sgr=\E[0;10%?%p1%t;7%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m%?%p5%t\E[=8F%;,
+ use=klone+sgr, use=klone+color,
+bsdos-pc|IBM PC BSD/OS Console,
+ sgr=\E[0;10%?%p1%t;7%;%?%p2%t;1%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m, use=bsdos-pc-nobold,
+
+# Old names for BSD/OS PC console used in releases before 4.1.
+pc3|BSD/OS on the PC Console,
+ use=bsdos-pc-nobold,
+ibmpc3|pc3-bold|BSD/OS on the PC Console with bold instead of underline,
+ use=bsdos-pc,
+
+# BSD/OS on the SPARC
+bsdos-sparc|Sun SPARC BSD/OS Console,
+ use=sun,
+
+# BSD/OS on the PowerPC
+bsdos-ppc|PowerPC BSD/OS Console,
+ use=bsdos-pc,
+
+#### DEC VT100 and compatibles
+#
+# DEC terminals from the vt100 forward (and the vt52, way obsolete but still
+# the basis of some emulations) 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.
+#
+
+# (<acsc>/<rmacs>/<smacs> capabilities aren't in DEC's official entry -- esr)
+vt52|dec vt52,
+ cols#80, it#8, lines#24,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, clear=\EH\EJ, cr=^M, cub1=\ED, cud1=\EB, cuf1=\EC,
+ cup=\EY%p1%{32}%+%c%p2%{32}%+%c, cuu1=\EA, ed=\EJ,
+ el=\EK, home=\EH, ht=^I, ind=^J, kbs=^H, kcub1=\ED, kcud1=\EB,
+ kcuf1=\EC, kcuu1=\EA, nel=^M^J, ri=\EI, rmacs=\EG, smacs=\EF,
+
+# 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.
+#
+# 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_|
+#
+# 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),
+ am, msgr, xenl, xon,
+ cols#80, it#8, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
+ 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=^J, ka1=\EOq,
+ ka3=\EOs, kb2=\EOr, kbs=^H, kc1=\EOp, kc3=\EOn, kcub1=\EOD,
+ kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kent=\EOM, kf0=\EOy,
+ kf1=\EOP, kf10=\EOx, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOt,
+ kf6=\EOu, kf7=\EOv, kf8=\EOl, kf9=\EOw, rc=\E8,
+ rev=\E[7m$<2>, ri=\EM$<5>, rmacs=^O, rmam=\E[?7l,
+ rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, 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%;,
+ sgr0=\E[m\017$<2>, smacs=^N, smam=\E[?7h, smkx=\E[?1h\E=,
+ smso=\E[7m$<2>, smul=\E[4m$<2>, tbc=\E[3g,
+vt100nam|vt100-nam|vt100 no automargins,
+ am@, xenl@, use=vt100-am,
+vt100-vb|dec vt100 (w/advanced video) & no beep,
+ bel@, flash=\E[?5h\E[?5l, use=vt100,
+
+# Ordinary vt100 in 132 column ("wide") mode.
+vt100-w|vt100-w-am|dec vt100 132 cols (w/advanced video),
+ cols#132, lines#24,
+ rs2=\E>\E[?3h\E[?4l\E[?5l\E[?8h, use=vt100-am,
+vt100-w-nam|vt100-nam-w|dec vt100 132 cols (w/advanced video no automargin),
+ cols#132, lines#14, vt@,
+ rs2=\E>\E[?3h\E[?4l\E[?5l\E[?8h, use=vt100-nam,
+
+# vt100 with no advanced video.
+vt100-nav|vt100 without advanced video option,
+ xmc#1,
+ blink@, bold@, rev@, rmso=\E[m, rmul@, sgr@, sgr0@, smso=\E[7m,
+ smul@,
+ use=vt100,
+vt100-nav-w|vt100-w-nav|dec vt100 132 cols 14 lines (no advanced video option),
+ cols#132, lines#14, use=vt100-nav,
+
+# vt100 with one of the 24 lines used as a status line.
+# We put the status line on the top.
+vt100-s|vt100-s-top|vt100-top-s|vt100 for use with top sysline,
+ eslok, hs,
+ lines#23,
+ clear=\E[2;1H\E[J$<50>, csr=\E[%i%i%p1%d;%p2%dr,
+ cup=\E[%i%p1%{1}%+%d;%p2%dH$<5>, dsl=\E7\E[1;24r\E8,
+ fsl=\E8, home=\E[2;1H, is2=\E7\E[2;24r\E8,
+ tsl=\E7\E[1;%p1%dH\E[1K, use=vt100-am,
+
+# Status line at bottom.
+# Clearing the screen will clobber status line.
+vt100-s-bot|vt100-bot-s|vt100 for use with bottom sysline,
+ eslok, hs,
+ lines#23,
+ dsl=\E7\E[1;24r\E8, fsl=\E8, is2=\E[1;23r\E[23;1H,
+ tsl=\E7\E[24;%p1%dH\E[1K,
+ use=vt100-am,
+
+# Most of the `vt100' emulators out there actually emulate a vt102
+# This entry (or vt102-nsgr) is probably the right thing to use for
+# these.
+vt102|dec vt102,
+ mir,
+ dch1=\E[P, dl1=\E[M, il1=\E[L, rmir=\E[4l, smir=\E[4h, use=vt100,
+vt102-w|dec vt102 in wide mode,
+ cols#132,
+ rs3=\E[?3h, use=vt102,
+
+# Many brain-dead PC comm programs that pretend to be `vt100-compatible'
+# fail to interpret the ^O and ^N escapes properly. Symptom: the <sgr0>
+# string in the canonical vt100 entry above leaves the screen littered
+# with little snowflake or star characters (IBM PC ROM character \017 = ^O)
+# after highlight turnoffs. This entry should fix that, and even leave
+# ACS support working, at the cost of making multiple-highlight changes
+# slightly more expensive.
+# From: Eric S. Raymond <esr@snark.thyrsus.com> July 22 1995
+vt102-nsgr|vt102 no sgr (use if you see snowflakes after highlight changes),
+ sgr@, sgr0=\E[m,
+ use=vt102,
+
+# VT125 Graphics CRT. Clear screen also erases graphics
+vt125|vt125 graphics terminal,
+ clear=\E[H\E[2J\EPpS(E)\E\\$<50>, use=vt100,
+
+# This isn't a DEC entry, it came from University of Wisconsin.
+# (vt131: I added <rmam>/<smam> based on the init string, also <OTbs> -- esr)
+vt131|dec vt131,
+ am, xenl,
+ cols#80, it#8, lines#24, vt#3,
+ bel=^G, blink=\E[5m$<2/>, bold=\E[1m$<2/>,
+ clear=\E[;H\E[2J$<50/>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=^J, cuf1=\E[C$<2/>,
+ cup=\E[%i%p1%d;%p2%dH$<5/>, cuu1=\E[A$<2/>,
+ ed=\E[J$<50/>, el=\E[K$<3/>, home=\E[H, ht=^I,
+ is2=\E[1;24r\E[24;1H, kbs=^H, kcub1=\EOD, kcud1=\EOB,
+ kcuf1=\EOC, kcuu1=\EOA, kf1=\EOP, kf2=\EOQ, kf3=\EOR,
+ kf4=\EOS, nel=^M^J, rc=\E8, rev=\E[7m$<2/>, ri=\EM$<5/>,
+ rmam=\E[?7h, rmkx=\E[?1l\E>, rmso=\E[m$<2/>,
+ rmul=\E[m$<2/>,
+ rs1=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
+ sgr0=\E[m$<2/>, smam=\E[?7h, smkx=\E[?1h\E=,
+ smso=\E[7m$<2/>, smul=\E[4m$<2/>,
+
+# vt132 - like vt100 but slower and has ins/del line and such.
+# I'm told that <smir>/<rmir> are backwards in the terminal from the
+# manual and from the ANSI standard, this describes the actual
+# terminal. I've never actually used a vt132 myself, so this
+# is untested.
+#
+vt132|DEC vt132,
+ xenl,
+ dch1=\E[P$<7>, dl1=\E[M$<99>, il1=\E[L$<99>, ind=\n$<30>,
+ ip=$<7>, rmir=\E[4h, smir=\E[4l,
+ use=vt100,
+
+# vt220:
+# This vt220 description maps F5--F9 to the second block of function keys
+# at the top of the keyboard. The "DO" key is used as F10 to avoid conflict
+# with the key marked (ESC) on the vt220. See vt220d for an alternate mapping.
+# PF1--PF4 are used as F1--F4.
+#
+vt220|vt200|DEC VT220 in vt100 emulation mode,
+ am, mir, xenl, xon,
+ cols#80, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>, civis=\E[?25l,
+ clear=\E[H\E[2J$<50>, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH$<10>, cuu1=\E[A, dch1=\E[P,
+ dl1=\E[M, ed=\E[J$<50>, el=\E[K$<3>, home=\E[H, ht=^I,
+ if=/usr/share/tabset/vt100, il1=\E[L, ind=\ED$<20/>,
+ is2=\E[1;24r\E[24;1H, kbs=^H, kcub1=\E[D, kcud1=\E[B,
+ kcuf1=\E[C, kcuu1=\E[A, kdch1=\E[3~, kend=\E[4~, kf1=\EOP,
+ kf10=\E[29~, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\E[17~,
+ kf6=\E[18~, kf7=\E[19~, kf8=\E[20~, kf9=\E[21~,
+ khome=\E[1~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~, rc=\E8,
+ rev=\E[7m$<2>, rf=/usr/share/tabset/vt100,
+ ri=\EM$<14/>, rmacs=\E(B$<4>, rmam=\E[?7l, rmir=\E[4l,
+ rmso=\E[27m, rmul=\E[24m,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
+ sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p4%t;5%;%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;,
+ sgr0=\E[m$<2>, smacs=\E(0$<2>, smam=\E[?7h, smir=\E[4h,
+ smso=\E[7m, smul=\E[4m,
+vt220-w|vt200-w|DEC vt220 in wide mode,
+ cols#132,
+ rs3=\E[?3h, use=vt220,
+
+#
+# vt220d:
+# This vt220 description regards F6--F10 as the second block of function keys
+# at the top of the keyboard. This mapping follows the description given
+# in the VT220 Programmer Reference Manual and agrees with the labeling
+# on some terminals that emulate the vt220. There is no support for an F5.
+# See vt220 for an alternate mapping.
+#
+vt220d|DEC VT220 in vt100 mode with DEC function key labeling,
+ kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
+ kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
+ kf18=\E[32~, kf19=\E[33~, kf20=\E[34~, kf5@, kf6=\E[17~,
+ kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
+ use=vt220,
+
+vt220-nam|v200-nam|VT220 in vt100 mode with no auto margins,
+ am@,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7l\E[?8h, use=vt220,
+
+# This is misnamed (see xterm-8bit for an example of 8-bit controls)
+vt220-8|dec vt220 8 bit terminal,
+ am, mc5i, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#24,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, clear=\E[H\E[J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
+ ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E)0,
+ flash=\E[?5h$<200/>\E[?5l, home=\E[H, ht=^I, hts=\EH,
+ ich=\E[%p1%d@, if=/usr/share/tabset/vt100,
+ il=\E[%p1%dL, il1=\E[L, ind=\ED,
+ is2=\E[?7h\E[>\E[?1h\E F\E[?4l, kbs=^H, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kf1=\EOP, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
+ kf17=\E[31~, kf18=\E[32~, kf19=\E[33~, kf2=\EOQ,
+ kf20=\E[34~, kf3=\EOR, kf4=\EOS, kf6=\E[17~, kf7=\E[18~,
+ kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, khlp=\E[28~,
+ khome=\E[H, kich1=\E[2~, knp=\E[6~, kpp=\E[5~, krdo=\E[29~,
+ kslt=\E[4~, lf1=pf1, lf2=pf2, lf3=pf3, lf4=pf4, mc0=\E[i,
+ mc4=\E[4i, mc5=\E[5i, nel=\EE, rc=\E8, rev=\E[7m, ri=\EM,
+ rmacs=^O, rmam=\E[?7l, rmir=\E[4l, rmso=\E[27m,
+ rmul=\E[24m, rs1=\E[?3l, sc=\E7, sgr0=\E[m, smacs=^N,
+ smam=\E[?7h, smir=\E[4h, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
+
+# vt220 termcap written Tue Oct 25 20:41:10 1988 by Alex Latzko
+# (not an official DEC entry!)
+# The problem with real vt220 terminals is they don't send escapes when in
+# in vt220 mode. This can be gotten around two ways. 1> don't send
+# escapes or 2> put the vt220 into vt100 mode and use all the nifty
+# features of vt100 advanced video which it then has.
+#
+# This entry takes the view of putting a vt220 into vt100 mode so
+# you can use the escape key in emacs and everything else which needs it.
+#
+# You probably don't want to use this on a VMS machine since VMS will think
+# it has a vt220 and will get fouled up coming out of emacs
+#
+# From: Alexander Latzko <latzko@marsenius.rutgers.edu>, 30 Dec 1996
+vt200-js|vt220-js|dec vt200 series with jump scroll,
+ am,
+ cols#80,
+ bel=^G, clear=\E[H\E[J, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=^J, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
+ dch1=\E[P, dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, ht=^I,
+ il1=\E[L, ind=\ED,
+ is2=\E[61"p\E[H\E[?3l\E[?4l\E[?1l\E[?5l\E[?6l\E[?7h\E[?8h\E[?25h\E>\E[m,
+ kbs=^H, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, nel=^M\ED,
+ rf=/usr/lib/tabset/vt100, ri=\EM, rmdc=, rmir=\E[4l,
+ rmkx=\E[?1l\E>, rmso=\E[27m$<5/>, rmul=\E[24m,
+ rs1=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, smdc=,
+ smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m$<5/>, smul=\E[4m,
+
+# This was DEC's vt320. Use the purpose-built one below instead
+#vt320|DEC VT320 in vt100 emulation mode,
+# use=vt220,
+
+#
+# Use v320n for SCO's LYRIX. Otherwise, use Adam Thompson's vt320-nam.
+#
+vt320nam|v320n|DEC VT320 in vt100 emul. mode with NO AUTO WRAP mode,
+ am@,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7l\E[?8h, use=vt220,
+
+# These entries are not DEC's official ones, they were purpose-built for the
+# VT320. Here are the designer's notes:
+# <kel> is end on a PC kbd. Actually 'select' on a VT. Mapped to
+# 'Erase to End of Field'... since nothing seems to use 'end' anyways...
+# khome is Home on a PC kbd. Actually 'FIND' on a VT.
+# Things that use <knxt> usually use tab anyways... and things that don't use
+# tab usually use <knxt> instead...
+# kprv is same as tab - Backtab is useless...
+# I left out <sgr> because of its RIDICULOUS complexity,
+# and the resulting fact that it causes the termcap translation of the entry
+# to SMASH the 1k-barrier...
+# From: Adam Thompson <thompson@xanth.magic.mb.ca> Sept 10 1995
+# (vt320: uncommented <fsl> --esr)
+vt320|vt300|dec vt320 7 bit terminal,
+ am, eslok, hs, mir, msgr, xenl,
+ cols#80, lines#24, wsl#80,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
+ ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K, fsl=\E[0$},
+ home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL,
+ il1=\E[L, ind=\ED,
+ is2=\E>\E[?3l\E[?4l\E[5?l\E[?7h\E[?8h\E[1;24r\E[24;1H,
+ ka1=\EOw, ka3=\EOy, kb2=\EOu, kbs=\177, kc1=\EOq, kc3=\EOs,
+ kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kdch1=\E[3~, kel=\E[4~, kent=\EOM, kf1=\EOP, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
+ kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
+ kf19=\E[33~, kf2=\EOQ, kf20=\E[34~, kf3=\EOR, kf4=\EOS,
+ kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
+ khome=\E[1~, kich1=\E[2~, knp=\E[6~, knxt=^I, kpp=\E[5~,
+ kprv=\E[Z, kslt=\E[4~, mc0=\E[i, mc4=\E[?4i, mc5=\E[?5i,
+ nel=\EE, rc=\E8, rev=\E[7m, rf=/usr/share/tabset/vt300,
+ ri=\EM, rmacs=\E(B, rmam=\E[?7l, rmir=\E[4l,
+ rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m,
+ rs2=\E>\E[?3l\E[?4l\E[5?l\E[?7h\E[?8h\E[1;24r\E[24;1H,
+ sc=\E7, sgr0=\E[m, smacs=\E(0, smam=\E[?7h, smir=\E[4h,
+ smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
+ tsl=\E[1$}\E[H\E[K,
+vt320-nam|vt300-nam|dec vt320 7 bit terminal with no am to make SAS happy,
+ am@,
+ is2=\E>\E[?3l\E[?4l\E[5?l\E[?7l\E[?8h\E[1;24r\E[24;1H,
+ rs2=\E>\E[?3l\E[?4l\E[5?l\E[?7l\E[?8h\E[1;24r\E[24;1H,
+ use=vt320,
+# We have to init 132-col mode, not 80-col mode.
+vt320-w|vt300-w|dec vt320 wide 7 bit terminal,
+ cols#132, wsl#132,
+ is2=\E>\E[?3h\E[?4l\E[5?l\E[?7h\E[?8h\E[1;24r\E[24;1H,
+ rs2=\E>\E[?3h\E[?4l\E[5?l\E[?7h\E[?8h\E[1;24r\E[24;1H,
+ use=vt320,
+vt320-w-nam|vt300-w-nam|dec vt320 wide 7 bit terminal with no am,
+ am@,
+ is2=\E>\E[?3h\E[?4l\E[5?l\E[?7l\E[?8h\E[1;24r\E[24;1H,
+ rs2=\E>\E[?3h\E[?4l\E[5?l\E[?7l\E[?8h\E[1;24r\E[24;1H,
+ use=vt320-w,
+
+# VT330 and VT340 -- These are ReGIS and SIXEL graphics terminals
+# which are pretty much a superset of the VT320. They have the
+# host writable status line, yet another different DRCS matrix size,
+# and such, but they add the DEC Technical character set, Multiple text
+# pages, selectable length pages, and the like. The difference between
+# the vt330 and vt340 is that the latter has only 2 planes and a monochrome
+# monitor, the former has 4 planes and a color monitor. These terminals
+# support VT131 and ANSI block mode, but as with much of these things,
+# termcap/terminfo doesn't deal with these features.
+#
+# Note that this entry is are set up in what was the standard way for GNU
+# Emacs v18 terminal modes to deal with the cursor keys in that the arrow
+# keys were switched into application mode at the same time the numeric pad
+# is switched into application mode. This changes the definitions of the
+# arrow keys. Emacs v19 is smarter and mines its keys directly out of
+# your termcap or terminfo entry,
+#
+# From: Daniel Glasser <dag@persoft.persoft.com>, 13 Oct 1993
+# (vt340: string capability "sb=\E[M" corrected to "sr";
+# also, added <rmam>/<smam> based on the init string -- esr)
+vt340|dec-vt340|vt330|dec-vt330|dec vt340 graphics terminal with 24 line page,
+ am, eslok, hs, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ blink=\E[5m, bold=\E[1m, civis=\E[?25l, clear=\E[H\E[J,
+ cnorm=\E[?25h, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
+ cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu=\E[%p1%dA, cuu1=\E[A, cvvis=\E[?25h, dch=\E[%p1%dP,
+ dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
+ dsl=\E[2$~\r\E[1$}\E[K\E[$}, ed=\E[J, el=\E[K,
+ flash=\E[?5h\E[?5l$<200/>, fsl=\E[$}, home=\E[H, ht=^I,
+ hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=\ED,
+ is2=\E<\E F\E>\E[?1h\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h\E[1;24r\E[24;1H,
+ kbs=^H, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf6=\E[17~,
+ kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, lf1=pf1, lf2=pf2,
+ lf3=pf3, lf4=pf4, nel=^M\ED, rc=\E8, rev=\E[7m,
+ rf=/usr/share/tabset/vt300, ri=\EM, rmacs=^O,
+ rmam=\E[?7l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[27m,
+ rmul=\E[24m, rs1=\E[?3l, sc=\E7, sgr0=\E[m, smacs=^N,
+ smam=\E[?7h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
+ smul=\E[4m, tbc=\E[3g, tsl=\E[2$~\E[1$}\E[1;%dH,
+
+# DEC doesn't supply a vt400 description, so we add Daniel Glasser's
+# (originally written with vt420 as its primary name, and usable for it).
+#
+# VT400/420 -- This terminal is a superset of the vt320. It adds the multiple
+# text pages and long text pages with selectable length of the vt340, along
+# with left and right margins, rectangular area text copy, fill, and erase
+# operations, selected region character attribute change operations,
+# page memory and rectangle checksums, insert/delete column, reception
+# macros, and other features too numerous to remember right now. TERMCAP
+# can only take advantage of a few of these added features.
+#
+# Note that this entry is are set up in what was the standard way for GNU
+# Emacs v18 terminal modes to deal with the cursor keys in that the arrow
+# keys were switched into application mode at the same time the numeric pad
+# is switched into application mode. This changes the definitions of the
+# arrow keys. Emacs v19 is smarter and mines its keys directly out of
+# your termcap entry,
+#
+# From: Daniel Glasser <dag@persoft.persoft.com>, 13 Oct 1993
+# (vt400: string capability ":sb=\E[M:" corrected to ":sr=\E[M:";
+# also, added <rmam>/<smam> based on the init string -- esr)
+vt400|vt400-24|dec-vt400|dec vt400 24x80 column autowrap,
+ am, eslok, hs, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[J$<10/>, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, dsl=\E[2$~\r\E[1$}\E[K\E[$}, ed=\E[J$<10/>,
+ el=\E[K$<4/>, flash=\E[?5h\E[?5l$<200/>, fsl=\E[$},
+ home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@,
+ il=\E[%p1%dL, il1=\E[L, ind=\ED,
+ is2=\E<\E F\E>\E[?1h\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h\E[1;24r\E[24;1H,
+ kbs=^H, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf6=\E[17~,
+ kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, lf1=pf1, lf2=pf2,
+ lf3=pf3, lf4=pf4, nel=^M\ED, rc=\E8, rev=\E[7m,
+ rf=/usr/share/tabset/vt300, ri=\EM, rmacs=^O,
+ rmam=\E[?7l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[27m,
+ rmul=\E[24m, rs1=\E<\E[?3l\E[!p\E[?7h, sc=\E7, sgr0=\E[m,
+ smacs=^N, smam=\E[?7h, smir=\E[4h, smkx=\E[?1h\E=,
+ smso=\E[7m, smul=\E[4m, tbc=\E[3g,
+ tsl=\E[2$~\E[1$}\E[1;%dH,
+
+# (vt420: I removed <kf0>, it collided with <kf10>. I also restored
+# a missing <sc> -- esr)
+vt420|DEC VT420,
+ am, mir, xenl, xon,
+ cols#80, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[2J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH$<10>, cuu1=\E[A, dch1=\E[P,
+ dl1=\E[M, ed=\E[J$<50>, el=\E[K$<3>, home=\E[H, ht=^I,
+ if=/usr/share/tabset/vt300, il1=\E[L, ind=\ED,
+ is2=\E[1;24r\E[24;1H, is3=\E[?67h\E[64;1"p, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kf1=\EOP, kf10=\E[29~, kf2=\EOQ, kf3=\EOR,
+ kf4=\EOS, kf5=\E[17~, kf6=\E[18~, kf7=\E[19~, kf8=\E[20~,
+ kf9=\E[21~, kfnd=\E[1~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~,
+ kslt=\E[4~, rc=\E8, rev=\E[7m$<2>,
+ rf=/usr/share/tabset/vt300, ri=\EM, rmacs=\E(B$<4>,
+ rmam=\E[?7l, rmir=\E[4l, rmkx=\E>,
+ rmsc=\E[?0;0r\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
+ rmso=\E[m, rmul=\E[m, rs3=\E[?67h\E[64;1"p, sc=\E7,
+ sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p4%t;5%;%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;,
+ sgr0=\E[m$<2>, smacs=\E(0$<2>, smam=\E[?7h, smir=\E[4h,
+ smkx=\E=, smso=\E[7m, smul=\E[4m,
+
+#
+# DEC VT220 and up support DECUDK (user-defined keys). DECUDK (i.e., pfx)
+# takes two parameters, the key and the string. Translating the key is
+# straightforward (keys 1-5 are not defined on real terminals, though some
+# emulators define these):
+#
+# if (key < 16) then value = key;
+# else if (key < 21) then value = key + 1;
+# else if (key < 25) then value = key + 2;
+# else if (key < 27) then value = key + 3;
+# else if (key < 30) then value = key + 4;
+# else value = key + 5;
+#
+# The string must be the hexadecimal equivalent, e.g., "5052494E" for "PRINT".
+# There's no provision in terminfo for emitting a string in this format, so the
+# application has to know it.
+#
+vt420pc|DEC VT420 w/PC keyboard,
+ kdch1=\177, kend=\E[4~, kf1=\E[11~, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[11;2~, kf14=\E[12;2~,
+ kf15=\E[13;2~, kf16=\E[14;2~, kf17=\E[15;2~,
+ kf18=\E[17;2~, kf19=\E[18;2~, kf2=\E[12~, kf20=\E[19;2~,
+ kf21=\E[20;2~, kf22=\E[21;2~, kf23=\E[23;2~,
+ kf24=\E[24;2~, kf25=\E[23~, kf26=\E[24~, kf27=\E[25~,
+ kf28=\E[26~, kf29=\E[28~, kf3=\E[13~, kf30=\E[29~,
+ kf31=\E[31~, kf32=\E[32~, kf33=\E[33~, kf34=\E[34~,
+ kf35=\E[35~, kf36=\E[36~, kf37=\E[23;2~, kf38=\E[24;2~,
+ kf39=\E[25;2~, kf4=\E[14~, kf40=\E[26;2~, kf41=\E[28;2~,
+ kf42=\E[29;2~, kf43=\E[31;2~, kf44=\E[32;2~,
+ kf45=\E[33;2~, kf46=\E[34;2~, kf47=\E[35;2~,
+ kf48=\E[36;2~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
+ kf8=\E[19~, kf9=\E[20~, khome=\E[H,
+ pctrm=USR_TERM\:vt420pcdos\:,
+ pfx=\EP1;1|%?%{16}%p1%>%t%{0}%e%{21}%p1%>%t%{1}%e%{25}%p1%>%t%{2}%e%{27}%p1%>%t%{3}%e%{30}%p1%>%t%{4}%e%{5}%;%p1%+%d/%p2%s\E\\, use=vt420,
+
+vt420pcdos|DEC VT420 w/PC for DOS Merge,
+ lines#25,
+ dispc=%?%p2%{19}%=%t\E\023\021%e%p2%{32}%<%t\E%p2%c%e%p2%{127}%=%t\E\177%e%p2%c%;,
+ pctrm@,
+ rmsc=\E[?0;0r\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sgr@,
+ sgr0=\E[m, smsc=\E[?1;2r\E[34h,
+ use=vt420pc,
+
+vt420f|DEC VT420 with VT kbd; VT400 mode; F1-F5 used as Fkeys,
+ kdch1=\177, kf1=\E[11~, kf10=\E[21~, kf11=\E[23~,
+ kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
+ kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
+ kf2=\E[12~, kf20=\E[34~, kf3=\E[13~, kf4=\E[14~,
+ kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
+ khome=\E[H, lf1=\EOP, lf2=\EOQ, lf3=\EOR, lf4=\EOS,
+ use=vt420,
+
+vt510|DEC VT510,
+ use=vt420,
+vt510pc|DEC VT510 w/PC keyboard,
+ use=vt420pc,
+vt510pcdos|DEC VT510 w/PC for DOS Merge,
+ use=vt420pcdos,
+
+# VT520/VT525
+#
+# The VT520 is a monochrome text terminal capable of managing up to
+# four independent sessions in the terminal. It has multiple ANSI
+# emulations (VT520, VT420, VT320, VT220, VT100, VT PCTerm, SCO Console)
+# and ASCII emulations (WY160/60, PCTerm, 50/50+, 150/120, TVI 950,
+# 925 910+, ADDS A2). This terminfo data is for the ANSI emulations only.
+#
+# Terminal Set-Up is entered by pressing [F3], [Caps Lock]/[F3] or
+# [Alt]/[Print Screen] depending upon which keyboard and which
+# terminal mode is being used. If Set-Up has been disabled or
+# assigned to an unknown key, Set-Up may be entered by pressing
+# [F3] as the first key after power up, regardless of keyboard type.
+# (vt520: I added <rmam>/<smam> based on the init string, also <sc> -- esr)
+vt520|DEC VT520,
+ am, mir, xenl, xon,
+ cols#80, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[2J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH$<10>, cuu1=\E[A, dch1=\E[P,
+ dl1=\E[M, ed=\E[J$<50>, el=\E[K$<3>, home=\E[H, ht=^I,
+ if=/usr/share/tabset/vt300, il1=\E[L, ind=\ED,
+ is2=\E[1;24r\E[24;1H, is3=\E[?67h\E[64;1"p, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kf0=\E[29~, kf1=\EOP, kf10=\E[29~, kf2=\EOQ,
+ kf3=\EOR, kf4=\EOS, kf5=\E[17~, kf6=\E[18~, kf7=\E[19~,
+ kf8=\E[20~, kf9=\E[21~, kfnd=\E[1~, kich1=\E[2~, knp=\E[6~,
+ kpp=\E[5~, kslt=\E[4~,
+ pfx=\EP1;1|%?%{16}%p1%>%t%{0}%e%{21}%p1%>%t%{1}%e%{25}%p1%>%t%{2}%e%{27}%p1%>%t%{3}%e%{30}%p1%>%t%{4}%e%{5}%;%p1%+%d/%p2%s\E\\,
+ rc=\E8, rev=\E[7m$<2>, rf=/usr/share/tabset/vt300,
+ ri=\EM, rmacs=\E(B$<4>, rmam=\E[?7l, rmir=\E[4l,
+ rmsc=\E[?0;0r\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
+ rmso=\E[m, rmul=\E[m, rs3=\E[?67h\E[64;1"p, sc=\E7,
+ sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p4%t;5%;%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;,
+ sgr0=\E[m$<2>, smacs=\E(0$<2>, smam=\E[?7h, smir=\E[4h,
+ smso=\E[7m, smul=\E[4m,
+
+# (vt525: I added <rmam>/<smam> based on the init string;
+# removed <rmso>=\E[m, <rmul>=\E[m, added <sc> -- esr)
+vt525|DEC VT525,
+ am, mir, xenl, xon,
+ cols#80, lines#24, vt#3,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[2J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH$<10>, cuu1=\E[A, dch1=\E[P,
+ dl1=\E[M, ed=\E[J$<50>, el=\E[K$<3>, home=\E[H, ht=^I,
+ if=/usr/share/tabset/vt300, il1=\E[L, ind=\ED,
+ is2=\E[1;24r\E[24;1H, is3=\E[?67h\E[64;1"p, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kf0=\E[29~, kf1=\EOP, kf10=\E[29~, kf2=\EOQ,
+ kf3=\EOR, kf4=\EOS, kf5=\E[17~, kf6=\E[18~, kf7=\E[19~,
+ kf8=\E[20~, kf9=\E[21~, kfnd=\E[1~, kich1=\E[2~, knp=\E[6~,
+ kpp=\E[5~, kslt=\E[4~,
+ pfx=\EP1;1|%?%{16}%p1%>%t%{0}%e%{21}%p1%>%t%{1}%e%{25}%p1%>%t%{2}%e%{27}%p1%>%t%{3}%e%{30}%p1%>%t%{4}%e%{5}%;%p1%+%d/%p2%s\E\\,
+ rc=\E8, rev=\E[7m$<2>, rf=/usr/share/tabset/vt300,
+ ri=\EM, rmacs=\E(B$<4>, rmam=\E[?7l, rmir=\E[4l,
+ rmsc=\E[?0;0r\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
+ rmso=\E[m, rmul=\E[m, rs3=\E[?67h\E[64;1"p, sc=\E7,
+ sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p4%t;5%;%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;,
+ sgr0=\E[m$<2>, smacs=\E(0$<2>, smam=\E[?7h, smir=\E[4h,
+ smso=\E[7m, smul=\E[4m,
+
+#### VT100 emulations
+#
+
+# John Hawkinson <jhawk@MIT.EDU> tells us that the EWAN telnet for Windows
+# (the best Windows telnet as of September 1995) presents the name `dec-vt100'
+# to telnetd. Michael Deutschmann <ldeutsch@mail.netshop.net> informs us
+# that this works best with a stock vt100 entry.
+dec-vt100|EWAN telnet's vt100 emulation,
+ use=vt100,
+
+# From: Adrian Garside <94ajg2@eng.cam.ac.uk>, 19 Nov 1996
+dec-vt220|DOS tnvt200 terminal emulator,
+ am@, use=vt220,
+
+# Zstem340 is an (IMHO) excellent VT emulator for PC's. I recommend it to
+# anyone who needs PC VT340 emulation. (or anything below that level, for
+# that matter -- DEC's ALL-in-1 seems happy with it, as does INFOPLUS's
+# RDBM systems, it includes ReGIS and SiXel support! I'm impressed...
+# I can send the address if requested.
+# (z340: changed garbled \E[5?l to \E[?5l, DEC smooth scroll off -- esr)
+# From: Adam Thompson <thompson@xanth.magic.mb.ca> Sept 10 1995
+z340|zstem vt340 terminal emulator 132col 42line,
+ lines#42,
+ is2=\E>\E[?3h\E[?4l\E[?5l\E[?7h\E[?8h\E[1;42r\E[42;1H,
+ rs2=\E>\E[?3h\E[?4l\E[?5l\E[?7h\E[?8h\E[1;42r\E[42;1H,
+ use=vt320-w,
+z340-nam|zstem vt340 terminal emulator 132col 42line (no automatic margins),
+ am@,
+ is2=\E>\E[?3h\E[?4l\E[?5l\E[?7l\E[?8h\E[1;42r\E[42;1H,
+ rs2=\E>\E[?3h\E[?4l\E[?5l\E[?7l\E[?8h\E[1;42r\E[42;1H,
+ use=z340,
+
+# CRT is shareware. It implements some xterm features, including mouse.
+crt|crt-vt220|CRT 2.3 emulating VT220,
+ bce, msgr,
+ colors#8, pairs#64,
+ hts=\EH, op=\E[39;49m, setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm, setb=\E[4%p1%dm, setf=\E[3%p1%dm,
+ u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,
+ use=vt220,
+
+# This entry is for Tera Term Pro version 2.3, for MS-Windows 95/NT written by
+# T. Teranishi dated Mar 10, 1998. It is a free software terminal emulator
+# (communication program) which supports:
+#
+# - Serial port connections.
+# - TCP/IP (telnet) connections.
+# - VT100 emulation, and selected VT200/300 emulation.
+# - TEK4010 emulation.
+# - File transfer protocols (Kermit, XMODEM, ZMODEM, B-PLUS and
+# Quick-VAN).
+# - Scripts using the "Tera Term Language".
+# - Japanese and Russian character sets.
+#
+# The program does not come with terminfo or termcap entries. However, the
+# emulation (testing with vttest and ncurses) is reasonably close to vt100 (no
+# vt52 or doublesize character support; blinking is done with color). Besides
+# the HPA, VPA extensions it also implements CPL and CNL.
+#
+# All of the function keys can be remapped. This description shows the default
+# mapping, as installed. Both vt100 PF1-PF4 keys and quasi-vt220 F1-F4 keys
+# are supported. F13-F20 are obtained by shifting F3-F10. The editing keypad
+# is laid out like vt220, rather than the face codes on the PC keyboard, i.e,
+# kfnd Insert
+# kslt Delete
+# kich1 Home
+# kdch1 PageUp
+# kpp End
+# knp PageDown
+#
+# ANSI colors are implemented, but cannot be combined with video attributes
+# except for reverse.
+#
+# No fonts are supplied with the program, so the acsc string is chosen to
+# correspond with the default Microsoft terminal font.
+#
+# Tera Term recognizes some xterm sequences, including those for setting and
+# retrieving the window title, and for setting the window size (i.e., using
+# "resize -s"), though it does not pass SIGWINCH to the application if the
+# user resizes the window with the mouse.
+teraterm|Tera Term Pro,
+ km, xon@,
+ ncv#43, vt@,
+ acsc=+\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,
+ blink=\E[5m, bold=\E[1m, civis=\E[?25l, clear=\E[H\E[J,
+ cnorm=\E[?25h, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
+ flash=\E[?5h\E[?5l$<200/>, hpa=\E[%i%p1%dG,
+ il=\E[%p1%dL, il1=\E[L, kdch1=\E[3~, kf1=\E[11~,
+ kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf13=\E[25~,
+ kf14=\E[26~, kf15=\E[28~, kf16=\E[29~, kf17=\E[31~,
+ kf18=\E[32~, kf19=\E[33~, kf2=\E[12~, kf20=\E[34~,
+ kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
+ kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~, kich1=\E[2~, knp=\E[6~,
+ kpp=\E[5~, kslt=\E[4~, op=\E[100m, rev=\E[7m, ri=\EM,
+ rmso=\E[27m, rmul=\E[24m, sgr0=\E[m, smso=\E[7m,
+ smul=\E[4m, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,
+ vpa=\E[%i%p1%dd,
+ use=klone+color, use=vt100,
+
+# Tested with WinNT 4.0, the telnet application assumes the screensize is
+# 25x80. This entry uses the 'Terminal' font, to get line-drawing characters.
+ms-vt100|MS telnet imitating dec vt100,
+ lines#25,
+ acsc=+\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,
+ tbc@, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?6c, u9=\E[c,
+ use=vt100,
+
+#### X terminal emulators
+#
+# You can add the following line to your .Xdefaults to change the terminal type
+# set by the xterms you start up to my-xterm:
+#
+# *termName: my-xterm
+#
+# System administrators can change the default entry for xterm instances
+# by adding a similar line to /usr/X11/lib/X11/app-defaults/XTerm. In either
+# case, xterm will detect and reject an invalid terminal type, falling back
+# to the default of xterm.
+#
+
+# X10/6.6 11/7/86, minus alternate screen, plus (csr)
+# (xterm: ":MT:" changed to ":km:"; added <smam>/<rmam> based on init string;
+# removed (hs, eslok, tsl=\E[?E\E[?%i%dT, fsl=\E[?F, dsl=\E[?E)
+# as these seem not to work -- esr)
+x10term|vs100-x10|xterm terminal emulator (X10 window system),
+ am, km, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#65,
+ bold=\E[1m, clear=\E[H\E[2J, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=^J, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH,
+ cuu1=\E[A, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, ht=^I, il=\E[%p1%dL,
+ il1=\E[L, ind=^J, is2=\E\E[m\E[?7h\E[?1;4l, kbs=^H,
+ kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kf1=\EOP,
+ kf2=\EOQ, kf3=\EOR, kf4=\EOS, rev=\E[7m, ri=\EM, rmam=\E[?7l,
+ rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m,
+ sgr0=\E[m, smam=\E[?7h, smir=\E[4h, smkx=\E[?1h\E=,
+ smso=\E[7m, smul=\E[4m,
+# Compatible with the R5 xterm
+# (from the XFree86 3.2 distribution, <blink=@> removed)
+# added khome/kend, rmir/smir, rmul/smul based on the R5 xterm code - TD
+# corrected typos in rs2 string - TD
+xterm-r5|xterm R5 version,
+ am, km, msgr, xenl,
+ cols#80, it#8, lines#24,
+ bel=^G, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, kbs=^H, kcub1=\EOD,
+ kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~,
+ kdl1=\E[31~, kel=\E[8~, kend=\E[4~, kf0=\EOq, kf1=\E[11~,
+ kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\E[12~,
+ kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
+ kf8=\E[19~, kf9=\E[20~, khome=\E[1~, kich1=\E[2~,
+ kil1=\E[30~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, rc=\E8,
+ rev=\E[7m, ri=\EM, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[m,
+ rmul=\E[m,
+ rs2=\E>\E[?1;3;4;5;6l\E[4l\E[?7h\E[m\E[r\E[2J\E[H,
+ sc=\E7,
+ sgr=\E[%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;m,
+ sgr0=\E[m, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m,
+ smul=\E[4m, tbc=\E[3g,
+# Compatible with the R6 xterm
+# (from XFree86 3.2 distribution, <acsc> and <it> added, <blink@> removed)
+# added khome/kend - TD
+xterm-r6|xterm-old|xterm X11R6 version,
+ am, km, mir, msgr, xenl,
+ cols#80, it#8, lines#24,
+ acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, enacs=\E)0, home=\E[H, ht=^I, il=\E[%p1%dL,
+ il1=\E[L, ind=^J,
+ is2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>, kbs=^H,
+ kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kdch1=\E[3~, kf1=\EOP, kf10=\E[21~, kf11=\E[23~,
+ kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
+ kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
+ kf2=\EOQ, kf20=\E[34~, kf3=\EOR, kf4=\EOS, kf5=\E[15~,
+ kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, kfnd=\E[1~,
+ kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~,
+ meml=\El, memu=\Em, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
+ rmcup=\E[2J\E[?47l\E8, rmir=\E[4l, rmkx=\E[?1l\E>,
+ rmso=\E[m, rmul=\E[m,
+ rs2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>, sc=\E7,
+ sgr0=\E[m, smacs=^N, smcup=\E7\E[?47h, smir=\E[4h,
+ smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m, tbc=\E[3g,
+ u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,
+# This is the base xterm entry for the xterm supplied with XFree86 3.2 & up.
+# The name has been changed and some aliases have been removed.
+xterm-xf86-v32|xterm terminal emulator (XFree86 3.2 Window System),
+ am, bce, km, mir, msgr, xenl,
+ colors#8, cols#80, it#8, lines#24, pairs#64,
+ acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
+ clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
+ enacs=\E(B\E)0, flash=\E[?5h\E[?5l, home=\E[H,
+ hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J,
+ is2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>,
+ ka1=\EOw, ka3=\EOu, kb2=\EOy, kbeg=\EOE, kbs=^H, kc1=\EOq,
+ kc3=\EOs, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
+ kdch1=\177, kend=\EOF, kent=\EOM, kf1=\E[11~, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
+ kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
+ kf19=\E[33~, kf2=\E[12~, kf20=\E[34~, kf3=\E[13~,
+ kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
+ kf9=\E[20~, kfnd=\E[1~, khome=\EOH, kich1=\E[2~,
+ kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~, meml=\El,
+ memu=\Em, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
+ rmam=\E[?7l, rmcup=\E[2J\E[?47l\E8, rmir=\E[4l,
+ rmkx=\E[?1l\E>, rmso=\E[27m, rmul=\E[24m, rs1=^O,
+ rs2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>, sc=\E7,
+ setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
+ setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;,
+ sgr0=\E[m\017, smacs=^N, smam=\E[?7h, smcup=\E7\E[?47h,
+ smir=\E[4h, smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m,
+ tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,
+ vpa=\E[%i%p1%dd,
+
+# This is the stock xterm entry supplied with XFree86 3.3, which uses VT100
+# codes for F1-F4 except while in VT220 mode.
+xterm-xf86-v33|xterm terminal emulator (XFree86 3.3 Window System),
+ kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
+ use=xterm-xf86-v32,
+
+# This version was released in XFree86 3.3.3 (November 1998).
+# Besides providing printer support, it exploits a new feature that allows
+# xterm to use terminfo-based descriptions with the titeInhibit resource.
+xterm-xf86-v333|xterm terminal emulator (XFree86 3.3.3 Window System),
+ mc5i,
+ blink=\E[5m, ich1@, invis=\E[8m,
+ is2=\E[!p\E[?3;4l\E[4l\E>, kdch1=\E[3~, kend=\E[4~,
+ kfnd@, khome=\E[1~, kslt@, mc0=\E[i, mc4=\E[4i, mc5=\E[5i,
+ rmcup=\E[?1047l\E[?1048l, rs1=\Ec,
+ rs2=\E[!p\E[?3;4l\E[4l\E>,
+ sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\016%e\017%;,
+ smcup=\E[?1048h\E[?1047h,
+ use=xterm-xf86-v33,
+
+# This beta version will probably be released in XFree86 4.0.
+xterm-xf86-v40|xterm terminal emulator (XFree86 4.0 Window System),
+ ka1=\EOH, ka3=\E[5~, kb2=\EOE, kc1=\EOF, kc3=\E[6~,
+ kdch1=\177, kend=\EOF, khome=\EOH, rmcup=\E[?1049l,
+ smcup=\E[?1049h,
+ use=xterm-xf86-v333,
+
+xterm-xfree86|xterm-new|xterm terminal emulator (XFree86 4.0 Window System),
+ use=xterm-xf86-v40,
+
+# From: David J. MacKenzie <djm@va.pubnix.com>, 14 Nov 1997
+xterm-xi|xterm on XI Graphics Accelerated X under BSD/OS 3.1,
+ rmso=\E[m, rmul=\E[m,
+ use=xterm-xf86-v33,
+
+# This is one of the variants of XFree86 3.3 xterm, updated for 4.0 (T.Dickey)
+xterm-16color|xterm with 16 colors like aixterm,
+ colors#16, ncv#32, pairs#256,
+ setab=\E[%?%p1%{8}%<%t%p1%{40}%+%e%p1%{92}%+%;%dm,
+ setaf=\E[%?%p1%{8}%<%t%p1%{30}%+%e%p1%{82}%+%;%dm,
+ setb=%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,
+ setf=%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,
+ use=xterm-xf86-v40,
+
+# This is another variant, for XFree86 4.0 xterm (T.Dickey)
+# This is an 8-bit version of xterm, which emulates DEC vt220 with ANSI color.
+# To use it, your decTerminalID resource must be set to 200 or above.
+#
+# HTS \E H \210
+# RI \E M \215
+# SS3 \E O \217
+# CSI \E [ \233
+#
+xterm-8bit|xterm terminal emulator 8-bit controls (X Window System),
+ am, bce, km, mc5i, mir, msgr, xenl,
+ colors#8, cols#80, it#8, lines#24, pairs#64,
+ acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\2335m, bold=\2331m, cbt=\233Z,
+ civis=\233?25l, clear=\233H\2332J, cnorm=\233?25h, cr=^M,
+ csr=\233%i%p1%d;%p2%dr, cub=\233%p1%dD, cub1=^H,
+ cud=\233%p1%dB, cud1=^J, cuf=\233%p1%dC, cuf1=\233C,
+ cup=\233%i%p1%d;%p2%dH, cuu=\233%p1%dA, cuu1=\233A,
+ cvvis=\233?25h, dch=\233%p1%dP, dch1=\233P,
+ dl=\233%p1%dM, dl1=\233M, ech=\233%p1%dX, ed=\233J,
+ el=\233K, el1=\2331K, enacs=\E(B\E)0,
+ flash=\233?5h\233?5l, home=\233H, hpa=\233%i%p1%dG,
+ ht=^I, hts=\210, ich=\233%p1%d@, il=\233%p1%dL, il1=\233L,
+ ind=^J, invis=\2338m,
+ is2=\E7\E G\233r\233m\233?7h\233?1;3;4;6l\2334l\E8\E>,
+ ka1=\217w, ka3=\217u, kb2=\217y, kbeg=\217E, kbs=^H,
+ kc1=\217q, kc3=\217s, kcub1=\217D, kcud1=\217B,
+ kcuf1=\217C, kcuu1=\217A, kdch1=\2333~, kend=\2334~,
+ kent=\217M, kf1=\23311~, kf10=\23321~, kf11=\23323~,
+ kf12=\23324~, kf13=\23325~, kf14=\23326~, kf15=\23328~,
+ kf16=\23329~, kf17=\23331~, kf18=\23332~, kf19=\23333~,
+ kf2=\23312~, kf20=\23334~, kf3=\23313~, kf4=\23314~,
+ kf5=\23315~, kf6=\23317~, kf7=\23318~, kf8=\23319~,
+ kf9=\23320~, khome=\2331~, kich1=\2332~, kmous=\233M,
+ knp=\2336~, kpp=\2335~, mc0=\233i, mc4=\2334i, mc5=\2335i,
+ meml=\El, memu=\Em, op=\23339;49m, rc=\E8, rev=\2337m,
+ ri=\215, rmacs=^O, rmam=\233?7l, rmcup=\233?1049l,
+ rmir=\2334l, rmkx=\233?1l\E>, rmso=\23327m, rmul=\23324m,
+ rs1=\Ec,
+ rs2=\E7\E[62"p\E G\233r\233m\233?7h\233?1;3;4;6l\2334l\E8\E>,
+ sc=\E7, setab=\2334%p1%dm, setaf=\2333%p1%dm,
+ setb=\2334%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ setf=\2333%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ sgr=\2330%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p7%t;8%;m%?%p9%t\016%e\017%;,
+ sgr0=\233m^O, smacs=^N, smam=\233?7h, smcup=\233?1049h,
+ smir=\2334h, smkx=\233?1h\E=, smso=\2337m, smul=\2334m,
+ tbc=\2333g, u6=\233[%i%d;%dR, u7=\E[6n, u8=\233[?1;2c,
+ u9=\E[c, vpa=\233%i%p1%dd,
+
+xterm-24|vs100|xterms|xterm terminal emulator (X Window System),
+ lines#24, use=xterm,
+
+# This is xterm for ncurses.
+xterm|xterm terminal emulator (X Window System),
+ acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ kmous=\E[M, u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?1;2c, u9=\E[c,
+ use=xterm-r6,
+
+# These entries allow access to the X titlebar and icon name as a status line.
+# Note that twm (and possibly window managers descended from it such as tvtwm,
+# ctwm, and vtwm) track windows by icon-name; thus, you don't want to mess
+# with it.
+xterm+sl|access X title line and icon name,
+ hs,
+ wsl#40,
+ dsl=\E]0;\007, fsl=^G, tsl=\E]0;, use=xterm,
+xterm+sl-twm|access X title line (pacify twm-descended window managers),
+ hs,
+ wsl#40,
+ dsl=\E]2;\007, fsl=^G, tsl=\E]2;, use=xterm,
+
+#
+# The following xterm variants don't depend on your base version
+#
+# xterm with bold instead of underline
+xterm-bold|xterm terminal emulator (X11R6 Window System) standout w/bold,
+ smso=\E[7m, smul=\E[1m,
+ use=xterm,
+# (kterm: this had extension capabilities ":KJ:TY=ascii:" -- esr)
+# (kterm should not invoke DEC Graphics as the alternate character set
+# -- Kenji Rikitake)
+kterm|kterm kanji terminal emulator (X window system),
+ eslok, hs,
+ acsc@, csr=\E[%i%p1%d;%p2%dr, dsl=\E[?H, enacs@, fsl=\E[?F,
+ kmous=\E[M, op=\E[39;49m, rc=\E8, rmacs@, sc=\E7, smacs@,
+ tsl=\E[?E\E[?%i%dT,
+ use=xterm-r6, use=klone+color,
+# See the note on ICH/ICH1 VERSUS RMIR/SMIR near the end of file
+xterm-nic|xterm with ich/ich1 suppressed for non-curses programs,
+ ich@, ich1@,
+ use=xterm,
+# From: Mark Sheppard <kimble@mistral.co.uk>, 4 May 1996
+xterm1|xterm terminal emulator ignoring the alternate screen buffer,
+ rmcup@, smcup@,
+ use=xterm,
+
+# This describes the capabilities of color_xterm, an xterm variant from
+# before ECMA-64 color support was folded into the main-line xterm release.
+# This entry is straight from color_xterm's maintainer.
+# From: Jacob Mandelson <jlm@ugcs.caltech.edu>, 09 Nov 1996
+# The README's with the distribution also say that it supports SGR 21, 24, 25
+# and 27, but they are not present in the terminfo or termcap.
+color_xterm|cx|cx100|color_xterm color terminal emulator for X,
+ am, km, mir, msgr, xenl,
+ colors#8, cols#80, it#8, lines#65, pairs#64,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, el1=\E[1K, enacs=\E(B\E)0, home=\E[H, ht=^I,
+ ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=^J,
+ is1=\E[r\E[m\E[?7h\E[?4;6l\E[4l, ka1=\EOw, ka3=\EOy,
+ kb2=\EOu, kbs=^H, kc1=\EOq, kc3=\EOs, kcub1=\EOD, kcud1=\EOB,
+ kcuf1=\EOC, kcuu1=\EOA, kend=\E[8~, kent=\EOM, kf1=\E[11~,
+ kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\E[12~,
+ kf3=\E[13~, kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~,
+ kf8=\E[19~, kf9=\E[20~, khome=\E[7~, kich1=\E[2~,
+ kmous=\E[M, knp=\E[6~, kpp=\E[5~, op=\E[39;49m, rc=\E8,
+ rev=\E[7m, ri=\EM, rmacs=^O, rmam=\E[?7l,
+ rmcup=\E>\E[?41;1r, rmir=\E[4l, rmso=\E[27m, rmul=\E[24m,
+ rs1=\E(B\017\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l\E<,
+ sc=\E7, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
+ sgr=\E[0%?%p1%p6%|%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;,
+ sgr0=\E[m, smacs=^N, smam=\E[?7h,
+ smcup=\E[?1;41s\E[?1;41h\E=, smir=\E[4h, smso=\E[7m,
+ smul=\E[4m,
+
+# The 'nxterm' distributed with Redhat Linux is a slight rehack of
+# xterm-sb_right-ansi-3d, which implements ANSI colors, but does not support
+# SGR 39 or 49. SGR 0 does reset colors (along with everything else). This
+# description is "compatible" with color_xterm, rxvt and XFree86 xterm, except
+# that each of those implements the home, end, delete keys differently.
+nxterm|xterm-color|generic color xterm,
+ ncv@,
+ op=\E[m, use=xterm-r6, use=klone+color,
+
+# From: Thomas Dickey <dickey@clark.net> 04 Oct 1997
+# Updated: Oezguer Kesim <kesim@math.fu-berlin.de> 02 Nov 1997
+# Notes:
+# rxvt 2.21b uses
+# smacs=\E(B\E)U^N, rmacs=\E(B\E)0^O,
+# but some applications don't work with that.
+# It also has an AIX extension
+# box2=lqkxjmwuvtn,
+# and
+# ech=\E[%p1%dX,
+# but the latter does not work correctly.
+#
+# The distributed terminfo says it implements hpa and vpa, but they are not
+# implemented correctly, using relative rather than absolute positioning.
+#
+# rxvt is normally configured to look for "xterm" or "xterm-color" as $TERM.
+# Since rxvt is not really compatible with xterm, it should be configured as
+# "rxvt" (monochrome) and "rxvt-color".
+rxvt-basic|rxvt terminal base (X Window System),
+ am, bce, eo, km, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#24,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ cvvis=\E[?25h, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0,
+ flash=\E[?5h\E[?5l, home=\E[H, ht=^I, hts=\EH,
+ ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J,
+ is1=\E[?47l\E=\E[?1l,
+ is2=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l,
+ kDC=\E[3$, kEND=\E[8$, kHOM=\E[7$, kLFT=\E[d, kNXT=\E[6$,
+ kPRV=\E[5$, kRIT=\E[c, ka1=\EOw, ka3=\EOy, kb2=\EOu, kbs=^H,
+ kc1=\EOq, kc3=\EOs, kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B,
+ kcuf1=\E[C, kcuu1=\E[A, kdch1=\E[3~, kel=\E[8\^,
+ kend=\E[8~, kent=\EOM, kf0=\E[21~, kf1=\E[11~, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
+ kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
+ kf19=\E[33~, kf2=\E[12~, kf20=\E[34~, kf3=\E[13~,
+ kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
+ kf9=\E[20~, kfnd=\E[1~, khome=\E[7~, kich1=\E[2~,
+ kmous=\E[M, knp=\E[6~, kpp=\E[5~, kslt=\E[4~, rc=\E8,
+ rev=\E[7m, ri=\EM, rmacs=^O, rmcup=\E[2J\E[?47l\E8,
+ rmir=\E[4l, rmkx=\E>, rmso=\E[27m, rmul=\E[24m,
+ rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H,
+ rs2=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;3;4;6l\E[4l\E>,
+ s0ds=\E(B, s1ds=\E(0, sc=\E7, sgr0=\E[0m\017, smacs=^N,
+ smcup=\E7\E[?47h, smir=\E[4h, smkx=\E=, smso=\E[7m,
+ smul=\E[4m, tbc=\E[3g,
+rxvt|rxvt terminal emulator (X Window System),
+ colors#8, pairs#64,
+ op=\E[39;49m, setab=\E[%p1%{40}%+%dm,
+ setaf=\E[%p1%{30}%+%dm, sgr0=\E[m\017, use=rxvt-basic,
+
+# These (xtermc and xtermm) are distributed with Solaris. They refer to a
+# variant of xterm which is apparently no longer supported, but are interesting
+# because they illustrate SVr4 curses mouse controls - T.Dickey
+xtermm|xterm terminal emulator (monocrome),
+ am, km, mir, msgr, xenl,
+ btns#3, cols#80, it#8, lines#24,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=@, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=\E[1D,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, el1=\E[1K$<3>, enacs=\E(B\E)0, getm=\E[%p1%dY,
+ home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, ka1=\EOq, ka3=\EOs, kb2=\EOr,
+ kbs=^H, kc1=\EOp, kc3=\EOn, kcub1=\EOD, kcud1=\EOB,
+ kcuf1=\EOC, kcuu1=\EOA, kend=\E[Y, kent=\EOM, kf0=\EOy,
+ kf1=\EOP, kf10=\EOY, kf11=\EOZ, kf12=\EOA, kf2=\EOQ,
+ kf3=\EOR, kf4=\EOS, kf5=\EOT, kf6=\EOU, kf7=\EOV, kf8=\EOW,
+ kf9=\EOX, khome=\E[H, kmous=\E[^_, knp=\E[U, kpp=\E[V,
+ rc=\E8, reqmp=\E[492Z, rev=\E[7m, ri=\EM, rmacs=^O,
+ rmcup=\E@0\E[?4r, rmso=\E[m,
+ rs1=\E>\E[1;3;4;5;6l\E[?7h\E[m\E[r\E[2J\E[H,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, 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%;,
+ sgr0=\E[m\017, smacs=^N, smcup=\E@0\E[?4s\E[?4h\E@1,
+ smso=\E[7m, tbc=\E[3g,
+
+xtermc|xterm terminal emulator (color),
+ colors#8, ncv#7, pairs#64,
+ op=\E[100m, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
+ setb=\E[4%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ setf=\E[3%?%p1%{1}%=%t4%e%p1%{3}%=%t6%e%p1%{4}%=%t1%e%p1%{6}%=%t3%e%p1%d%;m,
+ use=xtermm,
+
+# From: David J. MacKenzie <djm@va.pubnix.com> 20 Apr 1995
+# Here's a termcap entry I've been using for xterm_color, which comes
+# with BSD/OS 2.0, and the X11R6 contrib tape too I think. Besides the
+# color stuff, I also have a status line defined as the window manager
+# title bar. [I have translated it to terminfo -- ESR]
+xterm-pcolor|xterm with color used for highlights and status line,
+ bold=\E[1m\E[43m, rev=\E[7m\E[34m, smso=\E[7m\E[31m,
+ smul=\E[4m\E[42m,
+ use=xterm+sl, use=xterm-r6,
+
+# HP ships this, except for the pb#9600 which was merged in from BSD termcap.
+# (hpterm: added empty <acsc>, we have no idea what ACS chars look like --esr)
+hpterm|X-hpterm|hp X11 terminal emulator,
+ am, da, db, mir, xhp,
+ cols#80, lh#2, lines#24, lm#0, lw#8, nlab#8, pb#9600, xmc#0,
+ acsc=, bel=^G, bold=\E&dB, cbt=\Ei, clear=\E&a0y0C\EJ, cr=^M,
+ cub1=^H, cud1=\EB, cuf1=\EC, cup=\E&a%p1%dy%p2%dC,
+ cuu1=\EA, dch1=\EP, dim=\E&dH, dl1=\EM, ed=\EJ$<1>, el=\EK,
+ hpa=\E&a%p1%dC, ht=^I, hts=\E1, il1=\EL, ind=^J, kbs=^H,
+ kclr=\EJ, kctab=\E2, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kdch1=\EP, kdl1=\EM, ked=\EJ, kel=\EK, kf1=\Ep,
+ kf2=\Eq, kf3=\Er, kf4=\Es, kf5=\Et, kf6=\Eu, kf7=\Ev, kf8=\Ew,
+ khome=\Eh, khts=\E1, kich1=\EQ, kil1=\EL, kind=\ES, kll=\EF,
+ knp=\EU, kpp=\EV, kri=\ET, krmir=\ER, ktbc=\E3, meml=\El,
+ memu=\Em, pfkey=\E&f%p1%dk%p2%l%dL%p2%s,
+ pfloc=\E&f1a%p1%dk%p2%l%dL%p2%s,
+ pfx=\E&f2a%p1%dk%p2%l%dL%p2%s,
+ pln=\E&f%p1%dk%p2%l%dd0L%p2%s, rev=\E&dB, ri=\ET,
+ rmacs=^O, rmir=\ER, rmkx=\E&s0A, rmln=\E&j@, rmso=\E&d@,
+ rmul=\E&d@,
+ sgr=\E&d%?%p7%t%{115}%c%;%p1%p3%|%p6%|%{2}%*%p2%{4}%*%+%p4%+%p5%{8}%*%+%{64}%+%c%?%p9%t%'\016'%c%e%'\017'%c%;,
+ sgr0=\E&d@, smacs=^N, smir=\EQ, smkx=\E&s1A, smln=\E&jB,
+ smso=\E&dJ, smul=\E&dD, tbc=\E3, vpa=\E&a%p1%dY,
+
+# This entry describes an xterm with Sun-style function keys enabled
+# via the X resource setting "xterm*sunFunctionKeys:true"
+# To understand <kf11>/<kf12> note that L1,L2 and F11,F12 are the same.
+# The <kf13>...<kf20> keys are L3-L10. We don't set <kf16=\E[197z>
+# because we want it to be seen as <kcpy>.
+# The <kf31>...<kf45> keys are R1-R15. We treat some of these in accordance
+# with their Sun keyboard labels instead.
+# From: Simon J. Gerraty <sjg@zen.void.oz.au> 10 Jan 1996
+xterm-sun|xterm with sunFunctionKeys true,
+ kb2=\E[218z, kcpy=\E[197z, kend=\E[220z, kf1=\E[224z,
+ kf10=\E[233z, kf11=\E[192z, kf12=\E[193z, kf13=\E[194z,
+ kf14=\E[195z, kf15=\E[196z, kf17=\E[198z, kf18=\E[199z,
+ kf19=\E[200z, kf2=\E[225z, kf20=\E[201z, kf3=\E[226z,
+ kf31=\E[208z, kf32=\E[209z, kf33=\E[210z, kf34=\E[211z,
+ kf35=\E[212z, kf36=\E[213z, kf38=\E[215z, kf4=\E[227z,
+ kf40=\E[217z, kf42=\E[219z, kf44=\E[221z, kf5=\E[228z,
+ kf6=\E[229z, kf7=\E[230z, kf8=\E[231z, kf9=\E[232z,
+ kfnd=\E[200z, khlp=\E[196z, khome=\E[214z, kich1=\E[2z,
+ knp=\E[222z, kpp=\E[216z, kund=\E[195z,
+ use=xterm,
+xterms-sun|small (80x24) xterm with sunFunctionKeys true,
+ cols#80, lines#24, use=xterm-sun,
+
+# This is for the extensible terminal emulator on the X11R6 contrib tape.
+emu|emu native mode,
+ mir, msgr, xon,
+ colors#15, cols#80, it#8, lines#24, pairs#64, vt#200,
+ acsc=61a\202f\260g2j\213k\214l\215m\216n\217o\220q\222s\224t\225u\226v\227w\230x\231~\244,
+ bel=^G, blink=\ES\EW, bold=\ES\EU, civis=\EZ,
+ clear=\EP\EE0;0;, cnorm=\Ea, cr=^M, csr=\Ek%p1%d;%p2%d;,
+ cub=\Eq-%p1%d;, cub1=^H, cud=\Ep%p1%d;, cud1=\EB,
+ cuf=\Eq%p1%d;, cuf1=\ED, cup=\EE%p1%d;%p2%d;,
+ cuu=\Ep-%p1%d;, cuu1=\EA, cvvis=\Ea, dch=\EI%p1%d;,
+ dch1=\EI1;, dl=\ER%p1%d;, dl1=\ER1;, ech=\Ej%p1%d;, ed=\EN,
+ el=\EK, el1=\EL, enacs=\0, home=\EE0;0;, ht=^I, hts=\Eh,
+ il=\EQ%p1%d;, il1=\EQ1;, ind=\EG, is2=\ES\Er0;\Es0;,
+ kbs=^H, kcub1=\EC, kcud1=\EB, kcuf1=\ED, kcuu1=\EA,
+ kdch1=\177, kent=^M, kf0=\EF00, kf1=\EF01, kf10=\EF10,
+ kf11=\EF11, kf12=\EF12, kf13=\EF13, kf14=\EF14, kf15=\EF15,
+ kf16=\EF16, kf17=\EF17, kf18=\EF18, kf19=\EF19, kf2=\EF02,
+ kf20=\EF20, kf3=\EF03, kf4=\EF04, kf5=\EF05, kf6=\EF06,
+ kf7=\EF07, kf8=\EF08, kf9=\EF09, kfnd=\Efind, kich1=\Eins,
+ knp=\Enext, kpp=\Eprior, kslt=\Esel, oc=\Es0;\Er0;,
+ rev=\ES\ET, ri=\EF, rmacs=\0, rmir=\EX, rmso=\ES, rmul=\ES,
+ rs2=\ES\Es0;\Er0;, setab=\Es%i%p1%d;,
+ setaf=\Er%i%p1%d;, sgr0=\ES, smacs=\0, smir=\EY,
+ smso=\ES\ET, smul=\ES\EV, tbc=\Ej,
+
+#### MGR
+#
+# MGR is a Bell Labs window system lighter-weight than X.
+# These entries describe MGR's xterm-equivalent.
+# They are courtesy of Vincent Broman <broman@nosc.mil> 14 Jan 1997
+#
+
+mgr|Bellcore MGR (non X) window system terminal emulation,
+ am, km,
+ bel=^G, bold=\E2n, civis=\E9h, clear=^L, cnorm=\Eh, cr=^M,
+ csr=\E%p1%d;%p2%dt, cub1=^H, cud1=\Ef, cuf1=\Er,
+ cup=\E%p2%d;%p1%dM, cuu1=\Eu, cvvis=\E0h,
+ dch=\E%p1%dE$<5>, dch1=\EE, dl=\E%p1%dd$<3*>,
+ dl1=\Ed$<3>, ed=\EC, el=\Ec, hd=\E1;2f, ht=^I, hu=\E1;2u,
+ ich=\E%p1%dA$<5>, ich1=\EA, il=\E%p1%da$<3*>,
+ il1=\Ea$<3>, ind=^J, kbs=^H, kcub1=\E[D, kcud1=\E[B,
+ kcuf1=\E[C, kcuu1=\E[A, nel=^M^J, rev=\E1n, rmam=\E5S,
+ rmso=\E0n, rmul=\E0n, sgr0=\E0n, smam=\E5s, smso=\E1n,
+ smul=\E4n,
+mgr-sun|Mgr window with Sun keyboard,
+ ka1=\E[214z, ka3=\E[216z, kb2=\E[218z, kc1=\E[220z,
+ kc3=\E[222z, kcpy=\E197z, kend=\E[220z, kent=\E[250z,
+ kf1=\E[224z, kf10=\E[233z, kf11=\E[234z, kf12=\E[235z,
+ kf2=\E[225z, kf3=\E[226z, kf4=\E[227z, kf5=\E[228z,
+ kf6=\E[229z, kf7=\E[230z, kf8=\E[231z, kf9=\E[232z,
+ kfnd=\E[200z, khlp=\E[207z, khome=\E[214z, knp=\E[222z,
+ kopn=\E[198z, kpp=\E[216z, kund=\E[195z,
+ use=mgr,
+mgr-linux|Mgr window with Linux keyboard,
+ ka1=\E[H, ka3=\E[5~, kb2=\E[G, kc1=\E[Y, kc3=\E[6~,
+ kdch1=\E[3~, kend=\E[4~, kf0=\E[[J, kf1=\E[[A, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf2=\E[[B, kf3=\E[[C, kf4=\E[[D,
+ kf5=\E[[E, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
+ khome=\E[1~, knp=\E[6~, kpp=\E[5~,
+ use=mgr,
+
+######## UNIX VIRTUAL TERMINALS, VIRTUAL CONSOLES, AND TELNET CLIENTS
+#
+
+# Columbus UNIX virtual terminal. This terminal also appears in
+# UNIX 4.0 and successors as line discipline 1 (?), but is
+# undocumented and does not really work quite right.
+cbunix|cb unix virtual terminal,
+ am, da, db,
+ cols#80, lines#24, lm#0,
+ bel=^G, clear=\EL, cr=^M, cub1=^H, cud1=^J, cuf1=\EC,
+ cup=\EG%p2%c%p1%c, cuu1=\EA, dch1=\EM, dl1=\EN, ed=\EL,
+ el=\EK, ich1=\EO, il1=\EP, ind=^J, kcub1=\ED, kcud1=\EB,
+ kcuf1=\EC, kcuu1=\EA, khome=\EE, rmso=\Eb^D, rmul=\Eb^A,
+ smso=\Ea^D, smul=\Ea^A,
+# (vremote: removed obsolete ":nl@:" -- esr)
+vremote|virtual remote terminal,
+ am@,
+ cols#79, use=cbunix,
+
+pty|4bsd pseudo teletype,
+ cup=\EG%p1%{32}%+%c%p2%{32}%+%c, rmso=\Eb$, rmul=\Eb!,
+ smso=\Ea$, smul=\Ea!,
+ use=cbunix,
+
+# The codes supported by the term.el terminal emulation in GNU Emacs 19.30
+eterm|gnu emacs term.el terminal emulation,
+ am, mir, xenl,
+ cols#80, lines#24,
+ bel=^G, bold=\E[1m, clear=\E[H\E[J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, el1=\E[1K, home=\E[H, ht=^I, ich=\E[%p1%d@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, rev=\E[7m,
+ rmcup=\E[2J\E[?47l\E8, rmir=\E[4l, rmso=\E[m, rmul=\E[m,
+ sgr0=\E[m, smcup=\E7\E[?47h, smir=\E[4h, smso=\E[7m,
+ smul=\E[4m,
+
+# Entries for use by the FSF's `screen' program. The screen and
+# screen-w entries came with version 3.7.1. The screen2 and screen3 entries
+# come from University of Wisconsin and may be older.
+# (screen: added <cnorm> on ANSI model -- esr)
+
+screen|VT 100/ANSI X3.64 virtual terminal,
+ am, km, mir, msgr, xenl,
+ colors#8, cols#80, it#8, lines#24, pairs#64,
+ acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
+ clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
+ cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
+ dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0,
+ flash=\Eg, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kbs=^H, kcub1=\EOD,
+ kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kf1=\EOP,
+ kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR,
+ kf4=\EOS, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
+ kf9=\E[20~, khome=\E[1~, kich1=\E[2~, kll=\E[4~, knp=\E[6~,
+ kpp=\E[5~, nel=\EE, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
+ rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[23m, rmul=\E[24m,
+ rs2=\Ec, sc=\E7, sgr0=\E[m, smacs=^N, smir=\E[4h,
+ smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m, tbc=\E[3g,
+ use=ecma+color,
+
+screen-w|VT 100/ANSI X3.64 virtual terminal with 132 cols,
+ cols#132, use=screen,
+
+screen2|old VT 100/ANSI X3.64 virtual terminal,
+ cols#80, it#8, lines#24,
+ cbt=\E[Z, clear=\E[2J\E[H, cr=^M, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=\E[B, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=, il=\E[%p1%dL,
+ il1=\E[L, ind=^J, kbs=^H, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kf0=\E~, kf1=\ES, kf2=\ET, kf3=\EU, kf4=\EV,
+ kf5=\EW, kf6=\EP, kf7=\EQ, kf8=\ER, kf9=\E0I, khome=\EH,
+ nel=^M^J, rc=\E8, ri=\EM, rmir=\E[4l, rmso=\E[23m,
+ rmul=\E[24m, rs1=\Ec, sc=\E7, sgr0=\E[m, smir=\E[4h,
+ smso=\E[3m, smul=\E[4m, tbc=\E[3g,
+# (screen3: removed unknown ":xv:LP:G0:" -- esr)
+screen3|older VT 100/ANSI X3.64 virtual terminal,
+ km, mir, msgr,
+ cols#80, it#8, lines#24,
+ bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, clear=\E[H\E[J,
+ cr=^M, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J,
+ el=\E[K, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
+ il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kbs=^H, kcub1=\EOD,
+ kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kf1=\EOP, kf2=\EOQ,
+ kf3=\EOR, kf4=\EOS, nel=\EE, rc=\E8, rev=\E[7m, ri=\EM,
+ rmir=\E[4l, rmkx=\E>, rmso=\E[23m, rmul=\E[24m, rs1=\Ec,
+ sc=\E7, sgr0=\E[m, smir=\E[4h, smkx=\E=, smso=\E[3m,
+ smul=\E[4m, tbc=\E[3g,
+
+# Francesco Potorti <F.Potorti@cnuce.cnr.it>:
+# NCSA telnet is one of the most used telnet clients for the Macintosh. It has
+# been maintained until recently by the National Center for Supercomputer
+# Applications, and it is feature rich, stable and free. It can be downloaded
+# from www.ncsa.edu. This terminfo description file is based on xterm-vt220,
+# xterm+sl, and the docs at NCSA. It works well.
+#
+# NCSA Telnet 2.6 for Macintosh in vt220 8-bit emulation mode
+# The terminal options should be set as follows:
+# Xterm sequences ON
+# use VT wrap mode ON
+# use Emacs arrow keys OFF
+# CTRL-COMND is Emacs meta ON
+# 8 bit mode ON
+# answerback string: "ncsa-vt220-8"
+# setup keys: all disabled
+#
+# Application mode is not used. The documented function-key mapping refers to
+# the Apple Extended Keyboard (e.g., NCSA Telnet's F1 corresponds to a VT220
+# F6). We use the VT220-style codes, however, since the numeric keypad (VT100)
+# PF1-PF4 are available on some keyboards and many applications require these
+# as F1-F4.
+#
+# Other special mappings:
+# Apple VT220
+# HELP Find
+# HOME Insert here
+# PAGEUP Remove
+# DEL Select
+# END Prev Screen
+# PAGEDOWN Next Screen
+#
+# Though it supports ANSI color, NCSA Telnet uses color to represent blinking
+# text.
+#
+# The status-line manipulation is a mapping of the xterm-compatible control
+# sequences for setting the window-title. So you must use tsl and fsl in
+# pairs, since the latter ends the string that is loaded to the window-title.
+ncsa-m|ncsa-vt220|ncsa-vt220-8|NCSA Telnet 2.6 for Macintosh in vt220-8 mode,
+ am, hs, km, mir, msgr, xenl,
+ acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[2J, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M,
+ dsl=\E]0;\007, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E)0,
+ flash=\E[?5h\E[?5l, fsl=^G, home=\E[H, ht=^I, hts=\EH,
+ ich=\E[%p1%d@, if=/usr/share/tabset/vt100,
+ il=\E[%p1%dL, il1=\E[L, ind=^J,
+ is2=\E7\E[r\E[m\E[?7h\E[?1;4;6l\E[4l\E8\E>, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[4~, kend=\E[5~, kf1=\EOP, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
+ kf15=\E[28~, kf16=\E[29~, kf17=\E[31~, kf18=\E[32~,
+ kf19=\E[33~, kf2=\EOQ, kf20=\E[34~, kf3=\EOR, kf4=\EOS,
+ kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khlp=\E[1~,
+ khome=\E[2~, knp=\E[6~, kpp=\E[3~, mc4=\E[4i, mc5=\E[5i,
+ rc=\E8, rev=\E[7m, rf=/usr/share/tabset/vt100, ri=\EM,
+ rmacs=^O, rmam=\E[?7l, rmcup=\E[2J\E8, rmir=\E[4l,
+ rmso=\E[27m, rmul=\E[24m,
+ rs2=\E7\E[r\E[m\E[?7h\E[?1;4;6l\E[4l\E8\E>, sc=\E7,
+ sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p4%t;5%;%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;,
+ sgr0=\E[m\017, smacs=^N, smam=\E[?7h, smcup=\E7,
+ smir=\E[4h, smso=\E[7m, smul=\E[4m, tbc=\E[3g, tsl=\E]0;,
+ u6=\E[%i%d;%dR, u7=\E[6n, u8=\E[?62;1;6c, u9=\E[c,
+ncsa|NCSA Telnet 2.7 for Macintosh in vt220-8 mode,
+ use=ncsa-m, use=klone+color,
+ncsa-ns|NCSA Telnet 2.7 for Macintosh in vt220-8 mode,
+ hs@,
+ dsl@, fsl@, tsl@, use=ncsa,
+ncsa-m-ns|NCSA Telnet 2.6 for Macintosh in vt220-8 mode,
+ hs@,
+ dsl@, fsl@, tsl@, use=ncsa-m,
+
+#### Pilot Pro Palm-Top
+#
+# From: Jason Downs <downsj@downsj.com>, 15 Jun 1997 (Top Gun Telnet's author)
+pilot|tgtelnet|Top Gun Telnet on the Palm Pilot Professional,
+ am, xenl,
+ cols#39, lines#16,
+ bel=^G, clear=\Ec, cr=^M, cub1=^H, cud1=^J,
+ cup=\Em%p1%{32}%+%c%p2%{32}%+%c, home=\Em\s\s, ht=^I,
+ ind=^J, kbs=^H, kcub1=^H, kcud1=^J, knp=^L, kpp=^K, nel=\Em~\s,
+ rmso=\EB, smso=\Eb,
+
+######## COMMERCIAL WORKSTATION CONSOLES
+#
+
+#### Alpha consoles
+#
+
+# This is from the OSF/1 Release 1.0 termcap file
+pccons|pcconsole|ANSI (mostly) Alpha PC console terminal emulation,
+ am, xon,
+ cols#80, lines#25,
+ bel=^G, clear=\E[H\E[2J, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch1=\E[P, dl1=\E[M,
+ el=\E[K, home=\E[H, ht=^I, ich1=\E[@, il1=\E[L, kbs=^H,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, khome=\E[H,
+ nel=^M^J, rev=\E[7m, rmso=\E[m, sgr0=\E[m, smso=\E[7m,
+
+#### Sun consoles
+#
+
+# :is1: resets scrolling region in case a previous user had used "tset vt100"
+oldsun|Sun Microsystems Workstation console,
+ am, km, mir, msgr,
+ cols#80, it#8, lines#34,
+ bel=^G, clear=^L, cr=^M, cub1=^H, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch=\E[%p1%dP,
+ dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, ht=^I,
+ ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J,
+ is1=\E[1r, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, khome=\E[H,
+ rmso=\E[m, sgr0=\E[m, smso=\E[7m,
+# From: Alexander Lukyanov <lav@video.yars.free.net>, 14 Nov 1995
+# <lines> capability later corrected by J.T. Conklin <jtc@cygnus.com>
+# SGR 1, 4 aren't supported - removed bold/underline (T.Dickey 17 Jan 1998)
+sun-il|Sun Microsystems console with working insert-line,
+ am, km, msgr,
+ cols#80, lines#34,
+ bel=^G, bold@, clear=^L, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch=\E[%p1%dP,
+ dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, ht=^I,
+ ich=\E[%p1%d@, ich1=\E[@, il=\E[%p1%dL, il1=\E[L, ind=^J,
+ kb2=\E[218z, kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
+ kcuu1=\E[A, kdch1=\177, kend=\E[220z, kf1=\E[224z,
+ kf10=\E[233z, kf11=\E[234z, kf12=\E[235z, kf2=\E[225z,
+ kf3=\E[226z, kf4=\E[227z, kf5=\E[228z, kf6=\E[229z,
+ kf7=\E[230z, kf8=\E[231z, kf9=\E[232z, khome=\E[214z,
+ knp=\E[222z, kopt=\E[194z, kpp=\E[216z, kres=\E[193z,
+ kund=\E[195z, rev=\E[7m, rmso=\E[m, rmul@, rs2=\E[s,
+ sgr=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;m,
+ sgr0=\E[m, smso=\E[7m, smul@, u8=\E[1t, u9=\E[11t,
+# On a SparcStation 5, <il1>/<il> flake out on the last line.
+# Unfortunately, without them the terminal has no way to scroll.
+sun-ss5|Sun SparcStation 5 console,
+ il@, il1@, use=sun-il,
+# If you are using an SS5, change the sun definition to use sun-ss5.
+sun|sun1|sun2|Sun Microsystems Inc. workstation console,
+ use=sun-il,
+
+# From: <john@ucbrenoir> Tue Sep 24 13:14:44 1985
+sun-s|Sun Microsystems Workstation window with status line,
+ hs,
+ dsl=\E]l\E\\, fsl=\E\\, tsl=\E]l, use=sun,
+sun-e-s|sun-s-e|Sun Microsystems Workstation with status hacked for emacs,
+ hs,
+ dsl=\E]l\E\\, fsl=\E\\, tsl=\E]l, use=sun-e,
+sun-48|Sun 48-line window,
+ cols#80, lines#48, use=sun,
+sun-34|Sun 34-line window,
+ cols#80, lines#34, use=sun,
+sun-24|Sun 24-line window,
+ cols#80, lines#24, use=sun,
+sun-17|Sun 17-line window,
+ cols#80, lines#17, use=sun,
+sun-12|Sun 12-line window,
+ cols#80, lines#12, use=sun,
+sun-1|Sun 1-line window for sysline,
+ eslok, hs,
+ cols#80, lines#1,
+ dsl=^L, fsl=\E[K, tsl=^M, use=sun,
+sun-e|sun-nic|sune|Sun Microsystems Workstation without insert character,
+ ich1@, rmir@, smir@,
+ use=sun,
+sun-c|sun-cmd|Sun Microsystems Workstation console with scrollable history,
+ lines#35,
+ rmcup=\E[>4h, smcup=\E[>4l, use=sun,
+
+#### Iris consoles
+#
+
+# (wsiris: this had extension capabilities
+# :HS=\E7F2:HE=\E7F7:\
+# :CT#2:CZ=*Bblack,red,green,yellow,blue,magenta,cyan,*Fwhite:
+# See the note on Iris extensions near the end of this file.
+# Finally, removed suboptimal <clear>=\EH\EJ and added <cud1> &
+# <flash> from BRL -- esr)
+wsiris|iris40|iris emulating a 40 line visual 50 (approximately),
+ am,
+ cols#80, it#8, lines#40,
+ bel=^G, clear=\Ev, cnorm=\E>, cub1=^H, cud1=\EB, cuf1=\EC,
+ cup=\EY%p1%{32}%+%c%p2%{32}%+%c, cuu1=\EA, cvvis=\E;,
+ dim=\E7F2, dl1=\EM, ed=\EJ, el=\EK,
+ flash=\E7F4\E7B1\013\E7F7\E7B0, home=\EH, ht=^I, il1=\EL,
+ ind=^J, is2=\E7B0\E7F7\E7C2\E7R3, kcub1=\ED, kcud1=\EB,
+ kcuf1=\EC, kcuu1=\EA, kf0=\E0, kf1=\E1, kf2=\E2, kf3=\E3,
+ kf4=\E4, kf5=\E5, kf6=\E6, kf7=\E7, kf8=\E8, kf9=\E9, ri=\EI,
+ rmso=\E0@, rmul=\E7R3\E0@, sgr0=\E7F7, smso=\E9P,
+ smul=\E7R2\E9P,
+
+#### NeWS consoles
+#
+# Console terminal windows under the NeWS (Sun's Display Postscript windowing
+# environment). Note: these have nothing to do with Sony's News workstation
+# line.
+#
+
+# Entry for NeWS's psterm from Eric Messick & Hugh Daniel
+# (psterm: unknown ":sl=\EOl:el=\ENl:" removed -- esr)
+psterm|psterm-basic|NeWS psterm-80x34,
+ am, hs, km, ul,
+ cols#80, it#8, lines#34,
+ blink=\EOb, bold=\EOd, clear=^L, csr=\EE%p1%d;%p2%d;,
+ cub1=\ET, cud1=\EP, cuf1=\EV, cup=\E%p1%d;%p2%d;, cuu1=\EY,
+ dch1=\EF, dl1=\EK, ed=\EB, el=\EC, flash=\EZ, fsl=\ENl,
+ home=\ER, ht=^I, il1=\EA, ind=\EW, is1=\EN*, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, ll=\EU, rc=^\, rev=\EOr,
+ ri=\EX, rmcup=\ENt, rmir=\ENi, rmso=\ENo, rmul=\ENu, sc=^],
+ sgr0=\EN*, smcup=\EOt, smir=\EOi, smso=\EOo, smul=\EOu,
+ tsl=\EOl,
+psterm-96x48|NeWS psterm 96x48,
+ cols#96, lines#48, use=psterm,
+psterm-90x28|NeWS psterm 90x28,
+ cols#90, lines#28, use=psterm,
+psterm-80x24|NeWS psterm 80x24,
+ cols#80, lines#24, use=psterm,
+# This is a faster termcap for psterm. Warning: if you use this termcap,
+# some control characters you type will do strange things to the screen.
+# (psterm-fast: unknown ":sl=^Ol:el=^Nl:" -- esr)
+psterm-fast|NeWS psterm fast version (flaky ctrl chars),
+ am, hs, km, ul,
+ cols#80, it#8, lines#34,
+ blink=^Ob, bold=^Od, clear=^L, csr=\005%p1%d;%p2%d;,
+ cub1=^T, cud1=^P, cuf1=^V, cup=\004%p1%d;%p2%d;, cuu1=^Y,
+ dch1=^F, dl1=^K, ed=^B, el=^C, flash=^Z, fsl=^Nl, home=^R, ht=^I,
+ il1=^A, ind=^W, is1=^N*, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
+ kcuu1=\E[A, ll=^U, rc=^\, rev=^Or, ri=^X, rmcup=^Nt, rmir=^Ni,
+ rmso=^No, rmul=^Nu, sc=^], sgr0=^N*, smcup=^Ot, smir=^Oi,
+ smso=^Oo, smul=^Ou, tsl=^Ol,
+
+#### NeXT consoles
+#
+# Use `glasstty' for the Workspace application
+#
+
+# From: Dave Wetzel <dave@turbocat.snafu.de> 22 Dec 1995
+next|NeXT console,
+ am, xt,
+ cols#80, it#8, lines#24,
+ bel=^G, clear=^L, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, el=\E[K, home=\E[H,
+ ht=^I, ind=^J, kbs=^H, kcub1=^H, kcud1=^J, nel=^M^J,
+ rmso=\E[4;1m, sgr0=\E[m, smso=\E[4;2m,
+nextshell|NeXT Shell application,
+ am,
+ cols#80,
+ bel=^G, cr=^M, cub1=^H, cud1=^J, ht=^I, kbs=^H, kcub1=^H,
+ kcud1=^J, nel=^M^J,
+
+#### Sony NEWS workstations
+#
+
+# (news-unk: this had :KB=news: -- esr)
+news-unk|SONY NEWS vt100 emulator common entry,
+ am, xenl,
+ cols#80,
+ bel=^G, blink=\E[5m, bold=\E[1m, clear=\E[H\E[2J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dl=\E[%p1%dM, dl1=\E[M,
+ ed=\E[J, el=\E[K, home=\E[H, ht=^I,
+ if=/usr/lib/tabset/vt100, il=\E[%p1%dL, il1=\E[L,
+ is2=\E[?7h\E[?1l\E[?3l\E7\E8, kbs=^H, kcub1=\EOD,
+ kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kf0=\EOY, kf1=\EOP,
+ kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\EOT, kf6=\EOU, kf7=\EOV,
+ kf8=\EOW, kf9=\EOX, rc=\E8, rev=\E[7m, ri=\EM,
+ rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m, sc=\E7, sgr0=\E[m,
+ smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m,
+#
+# (news-29: this had :TY=ascii: --esr)
+news-29,
+ lines#29, use=news-unk,
+# (news-29-euc: this had :TY=euc: --esr)
+news-29-euc,
+ use=news-29,
+# (news-29-sjis: this had :TY=sjis: --esr)
+news-29-sjis,
+ use=news-29,
+#
+# (news-33: this had :TY=ascii: --esr)
+news-33,
+ lines#33, use=news-unk,
+# (news-33-euc: this had :TY=euc: --esr)
+news-33-euc,
+ use=news-33,
+# (news-33-sjis: this had :TY=sjis: --esr)
+news-33-sjis,
+ use=news-33,
+#
+# (news-42: this had :TY=ascii: --esr)
+news-42,
+ lines#42, use=news-unk,
+# (news-42-euc: this had :TY=euc: --esr)
+news-42-euc,
+ use=news-42,
+# (news-42-sjis: this had :TY=sjis: --esr)
+news-42-sjis,
+ use=news-42,
+#
+# NEWS-OS old termcap entry
+#
+# (news-old-unk: this had :KB=news:TY=sjis: --esr)
+news-old-unk|SONY NEWS vt100 emulator common entry,
+ am, xenl,
+ cols#80, vt#3,
+ bel=^G, blink=\E[5m, bold=\E[1m, clear=\E[;H\E[2J, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, ed=\E[J, el=\E[K,
+ home=\E[H, ht=^I, if=/usr/lib/tabset/vt100, kbs=^H,
+ kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kf1=\EOP,
+ kf2=\EOQ, kf3=\EOR, kf4=\EOS, rc=\E8, rev=\E[7m, ri=\EM,
+ rmkx=\E[?1l\E>, rmso=\E[m, rmul=\E[m, sc=\E7, sgr0=\E[m,
+ smkx=\E[?1h\E=, smso=\E[7m, smul=\E[4m,
+#
+# (nwp512: this had :DE=^H:, which I think means <OTbs> --esr)
+nwp512|news|nwp514|news40|vt100-bm|sony vt100 emulator 40 lines,
+ lines#40,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;40r\E8, use=news-old-unk,
+#
+# (nwp512-a: this had :TY=ascii: and the alias vt100-bm --esr)
+nwp512-a|nwp514-a|news-a|news42|news40-a|sony vt100 emulator 42 line,
+ lines#42,
+ is2=\E[?7h\E[?1l\E[?3l\E7\E[1;42r\E8, use=news-old-unk,
+#
+# (nwp-512-o: this had :KB=nwp410:DE=^H: I interpret the latter as <OTbs>. --esr)
+nwp512-o|nwp514-o|news-o|news40-o|vt100-bm-o|sony vt100 emulator 40 lines,
+ lines#40,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;40r\E8, use=news-old-unk,
+#
+# (nwp513: this had :DE=^H: and the alias vt100-bm --esr)
+nwp513|nwp518|nwe501|newscbm|news31|sony vt100 emulator 33 lines,
+ lines#31,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;31r\E8, use=news-old-unk,
+#
+# (nwp513-a: this had :TY=ascii: and :DE=^H:, which I interpret as <OTbs>; --esr)
+# also the alias vt100-bm.
+nwp513-a|nwp518-a|nwe501-a|nwp251-a|newscbm-a|news31-a|newscbm33|news33|sony vt100 emulator 33 lines,
+ lines#33,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;33r\E8, use=news-old-unk,
+#
+# (nwp513-o: had :DE=^H:, I think that's <OTbs>; also the alias vt100-bm --esr)
+nwp513-o|nwp518-o|nwe501-o|nwp251-o|newscbm-o|news31-o|sony vt100 emulator 33 lines,
+ lines#31,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;31r\E8, use=news-old-unk,
+#
+# (news28: this had :DE=^H:, I think that's <OTbs>, and :KB=nws1200: --esr)
+news28|sony vt100 emulator 28 lines,
+ lines#28,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;28r\E8, use=news-old-unk,
+#
+# (news29: this had :TY=ascii:KB=nws1200:\ --esr)
+news29|news28-a|sony vt100 emulator 29 lines,
+ lines#29,
+ is2=\E7\E[r\E8\EE\EE\EE\EM\EM\EM\E[?7h\E[?1l\E[?3l\E7\E[1;29r\E8, use=news-old-unk,
+#
+# (news511: this had :TY=sjis: --esr)
+nwp511|nwp-511|nwp-511 vt100,
+ am, xenl,
+ cols#80, lines#24,
+ clear=\E[;H\E[2J$<20/>, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A$<2/>, dl1=\E[M,
+ ed=\E[J$<30/>, el=\E[K$<3/>,
+ flash=\E[?5h\0\0\0\0\0\0\0\0\0\0\0\0\0\E[?5l,
+ il1=\E[L, is2=\E[?5l\E[?1l\E>\E[?7h\E[?8h, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kf1=\EOP, kf2=\EOQ,
+ kf3=\EOR, kf4=\EOS, kf5=\EOT, kf6=\E#W, khome=\E[H,
+ ri=\EM$<5/>, rmso=\E[m$<2/>, rmul=\E[m$<2/>,
+ smso=\E[7m$<2/>, smul=\E[4m$<2/>,
+# (news517: this had :TY=sjis:. --esr)
+nwp517|nwp-517|nwp-517 vt200 80 cols 30 rows,
+ eslok, hs,
+ cols#80, lines#30,
+ dsl=\E[1$~, fsl=\E[0$},
+ is2=\E7\E[r\E8\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
+ tsl=\E[1$}\E[;%df,
+ use=vt200,
+# (news517-w: this had :TY=sjis:. --esr)
+nwp517-w|nwp-517-w|nwp-517 vt200 132 cols 50 rows,
+ eslok, hs,
+ cols#132, lines#50,
+ dsl=\E[1$~, fsl=\E[0$},
+ is2=\E7\E[r\E8\E>\E[?3h\E[?4l\E[?5l\E[?7h\E[?8h,
+ tsl=\E[1$}\E[;%df,
+ use=vt200,
+
+#### Common Desktop Environment
+#
+
+# This ships with Sun's CDE in Solaris 2.5
+# Corrected Sun Aug 9 1998 by Alexander V. Lukyanov <lav@video.yars.free.net>
+dtterm|CDE desktop terminal,
+ am, mir, msgr, xenl, xon,
+ colors#8, cols#80, it#8, lines#24, lm#0, pairs#64,
+ acsc=``aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[H\E[J, cnorm=\E[?25h, cr=^M,
+ csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
+ dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[%p1%dM,
+ dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K, el1=\E[1K,
+ enacs=\E(B\E)0, flash=\E[?5h$<200>\E[?5l, home=\E[H,
+ ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L,
+ ind=\ED, invis=\E[8m, is2=\E F\E>\E[?1l\E[?7h\E[?45l,
+ kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kf1=\E[11~, kf10=\E[21~, kf11=\E[23~,
+ kf12=\E[24~, kf13=\E[25~, kf14=\E[26~, kf15=\E[28~,
+ kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
+ kf2=\E[12~, kf20=\E[34~, kf3=\E[13~, kf4=\E[14~,
+ kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
+ kfnd=\E[1~, khlp=\E[28~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~,
+ kslt=\E[4~, nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM,
+ rmacs=^O, rmam=\E[?7l, rmir=\E[4l, rmso=\E[22;27m,
+ rmul=\E[24m, sc=\E7, setab=\E[%p1%{40}%+%dm,
+ setaf=\E[%p1%{30}%+%dm,
+ sgr=\E[0%?%p1%t;2;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;%?%p7%t;8%;m%?%p9%t\016%e\017%;,
+ sgr0=\E[m\017, smacs=^N, smam=\E[?7h, smir=\E[4h,
+ smso=\E[2;7m, smul=\E[4m, tbc=\E[3g,
+
+#### Non-Unix Consoles
+#
+
+# Except for the "-emx" suffixes, these are as distributed with EMX 0.9b,
+# a Unix-style environment used on OS/2. (Note that the suffix makes some
+# names longer than 14 characters, the nominal maximum).
+#
+# Removed: rmacs=\E[10m, smacs=\E[11m, because OS/2 does not implement acs.
+ansi-emx|ANSI.SYS color,
+ am, bce, eo, mir, msgr, xenl, xon,
+ colors#16, cols#80, it#8, lines#25, pairs#64,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[1;33;44m\E[H\E[J, cnorm=\E[?25h, cr=^M, cub1=^H,
+ cud1=^J, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
+ dch=\E[%p1%dp, ed=\E[J, el=\E[K, flash=\E[?5h\E[?5l,
+ home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, ind=^J,
+ kb2=\E[G, kbs=^H, kcub1=\0K, kcud1=\0P, kcuf1=\0M, kcuu1=\0H,
+ kf0=\0D, kf1=\0;, kf2=\0<, kf3=\0=, kf4=\0>, kf5=\0?, kf6=\0@,
+ kf7=\0A, kf8=\0B, kf9=\0C, khome=\0G, kich1=\0R, kll=\0O,
+ knp=\0Q, kpp=\0I, kspd=^Z, nel=^M^J, rev=\E[5;37;41m,
+ rmir=\E[4l, rmpch=\E[10m, rmso=\E[0;44m\E[1;33m,
+ rmul=\E[0;44m\E[1;33m, rs1=\Ec, setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm, sgr0=\E[0m\E[1;33;44m, smir=\E[4h,
+ smpch=\E[11m, smso=\E[0;31;47m, smul=\E[1;31;44m,
+ tbc=\E[3g, u8=\E[?6c, u9=\E[c,
+ansi-color-2-emx|ANSI.SYS color 2,
+ am, bce, eo, mir, msgr, xenl, xon,
+ colors#16, cols#80, it#8, lines#25, pairs#64,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[0;37;44m\E[H\E[J, cnorm=\E[?25h, cr=^M, cub1=^H,
+ cud1=^J, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
+ dch=\E[%p1%dp, ed=\E[J, el=\E[K, flash=\E[?5h\E[?5l,
+ home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, ind=^J,
+ kb2=\E[G, kbs=^H, kcub1=\0K, kcud1=\0P, kcuf1=\0M, kcuu1=\0H,
+ kf0=\0D, kf1=\0;, kf2=\0<, kf3=\0=, kf4=\0>, kf5=\0?, kf6=\0@,
+ kf7=\0A, kf8=\0B, kf9=\0C, khome=\0G, kich1=\0R, kll=\0O,
+ knp=\0Q, kpp=\0I, kspd=^Z, nel=^M^J, rev=\E[1;37;46m,
+ rmir=\E[4l, rmpch=\E[10m, rmso=\E[0;37;44m,
+ rmul=\E[0;37;44m, rs1=\Ec, setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm, sgr0=\E[0;37;44m, smir=\E[4h,
+ smpch=\E[11m, smso=\E[1;37;46m, smul=\E[1;36;44m,
+ tbc=\E[3g, u8=\E[?6c, u9=\E[c,
+ansi-color-3-emx|ANSI.SYS color 3,
+ am, bce, eo, mir, msgr, xenl, xon,
+ colors#16, cols#80, it#8, lines#25, pairs#64,
+ bel=^G, blink=\E[5m, bold=\E[1m, civis=\E[?25l,
+ clear=\E[0;37;40m\E[H\E[J, cnorm=\E[?25h, cr=^M, cub1=^H,
+ cud1=^J, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
+ dch=\E[%p1%dp, ed=\E[J, el=\E[K, flash=\E[?5h\E[?5l,
+ home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, ich1=\E[@, ind=^J,
+ kb2=\E[G, kbs=^H, kcub1=\0K, kcud1=\0P, kcuf1=\0M, kcuu1=\0H,
+ kf0=\0D, kf1=\0;, kf2=\0<, kf3=\0=, kf4=\0>, kf5=\0?, kf6=\0@,
+ kf7=\0A, kf8=\0B, kf9=\0C, khome=\0G, kich1=\0R, kll=\0O,
+ knp=\0Q, kpp=\0I, kspd=^Z, nel=^M^J, rev=\E[1;37;46m,
+ rmir=\E[4l, rmpch=\E[10m, rmso=\E[0;37;40m,
+ rmul=\E[0;37;40m, rs1=\Ec, setab=\E[4%p1%dm,
+ setaf=\E[3%p1%dm, sgr0=\E[0;10m, smir=\E[4h,
+ smpch=\E[11m, smso=\E[1;37;46m, smul=\E[0;36;40m,
+ tbc=\E[3g, u8=\E[?6c, u9=\E[c,
+mono-emx|stupid monochrome ansi terminal with only one kind of emphasis,
+ am,
+ cols#80, it#8, lines#24,
+ clear=\E[H\E[2J$<50>, cub1=\E[D, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, el=\E[K, home=\E[H,
+ ht=^I, kb2=\E[G, kbs=^H, kcub1=\0K, kcud1=\0P, kcuf1=\0M,
+ kcuu1=\0H, kf0=\0D, kf1=\0;, kf2=\0<, kf3=\0=, kf4=\0>,
+ kf5=\0?, kf6=\0@, kf7=\0A, kf8=\0B, kf9=\0C, khome=\0G,
+ kich1=\0R, kll=\0O, knp=\0Q, kpp=\0I, nel=^M^J, rev=\E[7m,
+ sgr0=\E[0m,
+
+# This entry fits the Windows NT console when the _POSIX_TERM environment
+# variable is set to 'on'. While the Windows NT POSIX console is seldom used,
+# the Telnet client supplied with both the Windows for WorkGroup 3.11 TCP/IP
+# stack and the Win32 (i.e., Windows 95 and Windows NT 3.1 or later) operating
+# systems is not, and (surprise!) they match very well.
+#
+# See: MS Knowledge Base item Q108581, dated 13-MAY-1997, titled "Setting Up
+# VI POSIX Editor for Windows NT 3.1". True to Microsoft form, not only
+# are the installation instructions a pile of mind-numbing bureaucratese,
+# but the termcap entry is actually broken and unusable as given; the :do:
+# capability is misspelled "d".
+#
+# To use this, you need to a bunch of environment variables:
+#
+# SET _POSIX_TERM=on
+# SET TERM=ansi
+# SET TERMCAP=location of termcap file in POSIX file format
+# which is case-sensitive.
+# e.g. SET TERMCAP=//D/RESKIT35/posix/termcap
+# SET TMP=//C/TEMP
+#
+# Important note: setting the TMP environment variable in POSIX style renders
+# it incompatible with a lot of other applications, including Visual C++. So
+# you should have a separate command window just for vi. All the other
+# variables may be permanently set in the Control Panel\System applet.
+#
+# You can find out more about the restrictions of this facility at
+# <http://www.nentug.org/unix-to-nt/ntposix.htm>.
+#
+# From: Federico Bianchi <bianchi@magna.cisid.unipi.it>, 15 Jan 1997
+ansi-nt|psx_ansi|Microsoft Windows NT console POSIX ANSI mode,
+ am, bw, msgr,
+ cols#80, it#8, lines#25,
+ bel=^G, clear=\E[2J, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, ed=\E[J, el=\E[K,
+ home=\E[H, ht=^I, ind=\E[S, kbs=^H, kcub1=\E[D, kcud1=\E[V,
+ kcuf1=\E[C, kcuu1=\E[A, nel=\r\E[S, rc=\E[u, rev=\E[7m,
+ ri=\E[T, rmso=\E[m, sc=\E[s, sgr0=\E[0m, smso=\E[7m,
+
+######## COMMON TERMINAL TYPES
+#
+# This section describes terminal classes and maker brands that are still
+# quite common, but have proprietary command sets not blessed by ANSI.
+#
+
+#### Altos
+#
+# Altos made a moderately successful line of UNIX boxes. In 1990 they were
+# bought out by Acer, a major Taiwanese manufacturer of PC-clones.
+# Acer has a web site at http://www.acer.com.
+#
+# Altos descriptions from Ted Mittelstaedt <tedm@agora.rain.com> 4 Sep 1993
+# His comments suggest they were shipped with the system.
+#
+
+# (altos2: had extension capabilities
+# :c0=^A`\r:c1=^Aa\r:c2=^Ab\r:c3=^Ac\r:\
+# :c4=^Ad\r:c5=^Ae\r:c6=^Af\r:c7=^Ag\r:\
+# :c8=^Ah\r:c9=^Ai\r:cA=^Aj\r:cB=^Ak\r:\
+# :cC=^Al\r:cD=^Am\r:cE=^An\r:cF=^Ao\r:
+# :XU=^Aq\r:XD=^Ar\r:XR=^As\r:XL=^At\r:\
+# :YU=^AQ\r:YD=^AR\r:YR=^AS\r:YL=^AT\r:\
+# :HL=^AP\r:SP=\E[i:\
+# :IS=\E[@:DE=\E[P:IL=\E[L:NS=\E[S:PS=\E[T:\
+# :LO=\E[0q:LC=\E[5q:LL=\E[6q:\
+# Comparison with the k* capabilities makes it obvious that the c* things are
+# shift keys. I have renamed them to keys 32 and up accordingly. Also,
+# :sr: was given as a boolean-- esr)
+altos2|alt2|altos-2|altos II,
+ cols#80, it#8, lines#24, xmc#0,
+ clear=\E[H\E[2J, cr=^M, cub1=^H, cud1=\E[1B, cuf1=\E[1C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[1A, dch1=\E[P, dl=\E[M,
+ ed=\E[J, el=\E[K, home=\E[H, ht=^I, ich1=\E[@,
+ if=/usr/share/tabset/vt100, il1=\E[L, ind=^J,
+ is2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, kDL=^Am\r,
+ kEOL=^An\r, kbs=^H, kcbt=^AK\r, kclr=^AL\r, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, kdch1=^AM\r, kel=^AN\r,
+ kf0=^AI\r, kf1=^A@\r, kf2=^AA\r, kf3=^AB\r, kf32=^A`\r,
+ kf33=^Aa\r, kf34=^Ab\r, kf35=^Ac\r, kf36=^Ad\r, kf37=^Ae\r,
+ kf38=^Af\r, kf39=^Ag\r, kf4=^AC\r, kf40=^Ah\r, kf41=^Ai\r,
+ kf42=^Aj\r, kf43=^Ak\r, kf5=^AD\r, kf6=^AE\r, kf7=^AF\r,
+ kf8=^AG\r, kf9=^AH\r, khome=\E[f, kil1=^AJ\r, kind=^AO\r,
+ nel=^M^J, rmam=\E[?7l, rmso=\E[m, rmul=\E[m, sgr0=\E[m,
+ smam=\E[?7h, smso=\E[7m, smul=\E[4m,
+# (altos3: had extension capabilities
+# :c0=^A`\r:c1=^Aa\r:c2=^Ab\r:c3=^Ac\r:\
+# :c4=^Ad\r:c5=^Ae\r:c6=^Af\r:c7=^Ag\r:\
+# :c8=^Ah\r:c9=^Ai\r:cA=^Aj\r:cB=^Ak\r:\
+# :cC=^Al\r:cD=^Am\r:cE=^An\r:cF=^Ao\r:
+# :XU=^Aq\r:XD=^Ar\r:XR=^As\r:XL=^At\r:\
+# :HL=^AP\r:SP=\E[i:\
+# :IS=\E[@:DE=\E[P:IL=\E[L:NS=\E[S:PS=\E[T:\
+altos3|altos5|alt3|alt5|altos-3|altos-5|altos III or V,
+ blink=\E[5p, ri=\EM, sgr0=\E[p,
+ use=altos2,
+altos4|alt4|altos-4|altos IV,
+ use=wy50,
+# (altos7: had extension capabilities:
+# :GG#0:GI=\EH8:GF=\EH7:\
+# :c0=^A`\r:c1=^Aa\r:c2=^Ab\r:c3=^Ac\r:\
+# :c4=^Ad\r:c5=^Ae\r:c6=^Af\r:c7=^Ag\r:\
+# :c8=^Ah\r:c9=^Ai\r:cA=^Aj\r:cB=^Ak\r:\
+# :cC=^Al\r:cD=^Am\r:cE=^An\r:cF=^Ao\r:
+# Comparison with the k* capabilities makes it obvious that the c* things are
+# shift keys. I have renamed them to keys 32 and up accordingly. I have
+# also made this entry relative to adm12 in order to give it an <sgr>. The
+# <invis> imported by use=adm+sgr may work, let me know. -- esr)
+altos7|alt7|altos VII,
+ am, mir,
+ cols#80, lines#24, xmc#0,
+ acsc=j5k3l2m1n8q\:t4u9v=w0x6, blink=\EG2, bold=\EGt,
+ clear=\E+^^, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dim=\EGp, dl=\ER, ed=\EY, el=\ET, home=^^, ht=^I, il1=\EE,
+ ind=^J, invis=\EG1,
+ is2=\E`\:\Ee(\EO\Ee6\Ec41\E~4\Ec21\Eu\E~2, kDL=^Am\r,
+ kEOL=^An\r, kbs=^H, kcbt=^AK\r, kclr=^AL\r, kcub1=^H,
+ kcud1=^J, kcuf1=^L, kcuu1=^K, kdch1=^AM\r, kel=^AN\r,
+ kf0=^AI\r, kf1=^A@\r, kf2=^AA\r, kf3=^AB\r, kf32=^A`\r,
+ kf33=^Aa\r, kf34=^Ab\r, kf35=^Ac\r, kf36=^Ad\r, kf37=^Ae\r,
+ kf38=^Af\r, kf39=^Ag\r, kf4=^AC\r, kf40=^Ah\r, kf41=^Ai\r,
+ kf42=^Aj\r, kf43=^Ak\r, kf5=^AD\r, kf6=^AE\r, kf7=^AF\r,
+ kf8=^AG\r, kf9=^AH\r, khome=^^, kil1=^AJ\r, kind=^AO\r,
+ knp=\EK, kpp=\EJ, mc4=\EJ, mc5=\Ed#, nel=^M^J, ri=\Ej,
+ rmir=\Er, smir=\Eq,
+ use=adm+sgr,
+altos7pc|alt7pc|altos PC VII,
+ kend=\ET, use=altos7,
+
+#### Hewlett-Packard (hp)
+#
+# Hewlett-Packard
+# 8000 Foothills Blvd
+# Roseville, CA 95747
+# Vox: 1-(916)-785-4363 (Technical response line for VDTs)
+# 1-(800)-633-3600 (General customer support)
+#
+
+# Generic HP terminal - this should (hopefully) work on any HP terminal.
+hpgeneric|hp|hewlett-packard generic terminal,
+ am, da, db, mir, xhp,
+ cols#80, lines#24, lm#0, vt#6,
+ bel=^G, clear=\EH\EJ, cr=^M, cub1=^H, cud1=^J, cuf1=\EC,
+ cup=\E&a%p2%dc%p1%dY$<6>, cuu1=\EA, dch1=\EP, dl1=\EM,
+ ed=\EJ, el=\EK, hpa=\E&a%p1%dC, ht=^I, hts=\E1, il1=\EL,
+ ind=^J, kbs=^H, kcbt=\Ei, rmir=\ER, rmso=\E&d@, rmul=\E&d@,
+ sgr0=\E&d@, smir=\EQ, smso=\E&dJ, smul=\E&dD, tbc=\E3,
+ vpa=\E&a%p1%dY,
+
+hp110|hewlett-packard model 110 portable,
+ lines#16, use=hpgeneric,
+
+hp+pfk+cr|hp function keys with CR,
+ kf1=\Ep\r, kf2=\Eq\r, kf3=\Er\r, kf4=\Es\r, kf5=\Et\r,
+ kf6=\Eu\r, kf7=\Ev\r, kf8=\Ew\r,
+
+hp+pfk-cr|hp function keys w/o CR,
+ kf1=\Ep, kf2=\Eq, kf3=\Er, kf4=\Es, kf5=\Et, kf6=\Eu, kf7=\Ev,
+ kf8=\Ew,
+
+# The hp2621s use the same keys for the arrows and function keys,
+# but not separate escape sequences. These definitions allow the
+# user to use those keys as arrow keys rather than as function
+# keys.
+hp+pfk+arrows|hp alternate arrow definitions,
+ kcub1=\Eu\r, kcud1=\Ew\r, kcuf1=\Ev\r, kcuu1=\Et\r, kf1@,
+ kf2@, kf3@, kf4@, kf5@, kf6@, kf7@, kf8@, khome=\Ep\r, kind=\Er\r,
+ kll=\Eq\r, kri=\Es\r,
+
+hp+arrows|hp arrow definitions,
+ kcub1=\ED, kcud1=\EB, kcuf1=\EC, kcuu1=\EA, khome=\Eh,
+ kind=\ES, kll=\EF, kri=\ET,
+
+# Generic stuff from the HP 262x series
+#
+hp262x|HP 262x terminals,
+ xhp,
+ blink=\E&dA, dch1=\EP$<2>, ed=\EJ, ht=\011$<2>, ind=\ES,
+ invis=\E&dS, ip=$<2>, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kdch1=\EP, kdl1=\EM, ked=\EJ, kel=\EK, khome=\Eh,
+ kich1=\EQ, kil1=\EL, kind=\ES, knp=\EU, kpp=\EV, kri=\ET,
+ krmir=\ER, rev=\E&dB, rmkx=\E&s0A, rmso=\E&d@, rmul=\E&d@,
+ sgr=\E&d%{64}%?%p1%t%{66}%|%;%?%p2%t%{68}%|%;%?%p3%t%{66}%|%;%?%p4%t%{65}%|%;%c,
+ sgr0=\E&d@, smkx=\E&s1A, smso=\E&dB, smul=\E&dD,
+
+# Note: no <home> on HPs since that homes to top of memory, not screen.
+# Due to severe 2621 braindamage, the only way to get the arrow keys to
+# transmit anything at all is to turn on the function key labels
+# with <smkx>, and even then the user has to hold down shift!
+# The default 2621 turns off the labels except when it has to to
+# enable the function keys. If your installation prefers labels
+# on all the time, or off all the time (at the "expense" of the
+# function keys), use 2621-nl or 2621-wl.
+#
+# Note: there are newer ROMs for 2621's that allow you to set
+# strap A so the regular arrow keys xmit \EA, etc, as with the
+# 2645. However, even with this strap set, the terminal stops
+# xmitting if you reset it, until you unset and reset the strap!
+# Since there is no way to set/unset the strap with an escape
+# sequence, we don't use it in the default.
+# If you like, you can use 2621-ba (brain-damaged arrow keys).
+hp2621-ba|2621 w/new rom and strap A set,
+ rmkx@, smkx@, use=hp+arrows,
+ use=hp2621,
+
+# hp2621 with function labels. Most of the time they are off,
+# but inside vi, the function key labels appear. You have to
+# hold down shift to get them to xmit.
+hp2621|hp2621a|hp2621A|2621|2621a|2621A|hp2621-wl|2621-wl|hp 2621 w/labels,
+ is2=\E&jA\r, rmkx=\E&jA,
+ use=hp2621-fl,
+hp2621-fl|hp 2621,
+ xhp@, xon,
+ pb#19200,
+ cbt=\Ei, cup=\E&a%p2%dc%p1%dY, dch1=\EP$<2>, ht=\011$<2>,
+ ip=$<2>, is2=\E&j@\r, rmkx=\E&j@, rmso=\E&d@, rmul=\E&d@,
+ sgr0=\E&d@, smkx=\E&jB, smso=\E&dD, smul=\E&dD,
+ use=hp+pfk+cr, use=hpgeneric,
+
+# To use hp2621p printer, setenv TERM=2621p, PRINTER=2612p
+hp2621p|hp 2621 with printer,
+ mc4=\E&p13C, mc5=\E&p11C, use=hp2621,
+
+hp2621p-a|hp2621p with fn as arrows,
+ use=hp+pfk+arrows, use=hp2621p,
+
+# hp2621 with k45 keyboard
+hp2621-k45|hp2621k45|k45|hp 2621 with 45 keyboard,
+ kbs=^H, kcub1=\ED, kcud1=\EB, kcuf1=\EC, kcuu1=\EA,
+ khome=\Eh, rmkx=\E&s0A, smkx=\E&s1A,
+ use=hp2621,
+
+# 2621 using all 48 lines of memory, only 24 visible at any time.
+hp2621-48|48 line 2621,
+ lines#48,
+ cup=\E&a%p2%dc%p1%dR, home=\EH, vpa=\E&a%p1%dR, use=hp2621,
+
+# 2621 with no labels ever. Also prevents vi delays on escape.
+hp2621-nl|hp 2621 with no labels,
+ kcub1@, kcud1@, kcuf1@, kcuu1@, khome@, rmkx@, smkx@, use=hp2621-fl,
+
+# Needed for UCB ARPAVAX console, since lsi-11 expands tabs
+# (wrong).
+#
+hp2621-nt|hp 2621 w/no tabs,
+ ht@, use=hp2621,
+
+# Hp 2624 B with 4 or 10 pages of memory.
+#
+# Some assumptions are made with this entry. These settings are
+# NOT set up by the initialization strings.
+#
+# Port Configuration
+# RecvPace=Xon/Xoff
+# XmitPace=Xon/Xoff
+# StripNulDel=Yes
+#
+# Terminal Configuration
+# InhHndShk=Yes
+# InhDC2=Yes
+# XmitFnctn(A)=No
+# InhEolWrp=No
+#
+# Note: the 2624 DOES have a true <home>, believe it or not!
+#
+# The 2624 has an "error line" to which messages can be sent.
+# This is CLOSE to what is expected for a "status line". However,
+# after a message is sent to the "error line", the next carriage
+# return is EATEN and the "error line" is turned back off again!
+# So I guess we can't define <hs>, <eslok>, <wsl>, <dsl>, <fsl>, <tsl>.
+#
+# This entry supports emacs (and any other program that uses raw
+# mode) at 4800 baud and less. I couldn't get the padding right
+# for 9600.
+#
+# (hp2624: replaced NUL sequences in flash with mandatory pauses -- esr)
+hp2624|hp2624a|hp2624b|hp2624b-4p|Hewlett Packard 2624 B,
+ da, db,
+ lm#96,
+ flash=\E&w13F$<66/>\E&w12F$<66/>\E&w13F$<66/>\E&w12F, use=hp+labels, use=scrhp,
+
+# This hp2626 entry does not use any of the fancy windowing stuff
+# of the 2626.
+#
+# Indeed, terminfo does not yet handle such stuff. Since changing
+# any window clears memory, it is probably not possible to use
+# this for screen opt.
+#
+# ed is incredibly slow most of the time - I am guessing at the
+# exact padding. Since the terminal uses xoff/xon this is intended
+# only for cost computation, so that the terminal will prefer el
+# or even dl1 which is probably faster!
+#
+# \ED\EJ\EC hack for ed from Ed Bradford - apparently ed is only
+# extra slow on the last line of the window.
+#
+# The padding probably should be changed.
+#
+hp2626|hp2626a|hp2626p|hp 2626,
+ da, db,
+ lm#0, pb#19200,
+ ed=\ED\EJ$<500>\EC, indn=\E&r%p1%dD, ip=$<4>,
+ is2=\E&j@\r, rin=\E&r%p1%dU,
+ use=hp+pfk+cr, use=hp+labels, use=scrhp,
+
+# This entry is for sysline. It allocates a 23 line window with
+# a 115 line workspace for regular use, and a 1 line window for
+# the status line.
+#
+# This assumes port 2 is being used.
+# Turn off horizontal line, Create ws #1 with 115 lines,
+# Create ws #2 with 1 line, Create window #1 lines 1-23,
+# Create window #2 lines 24-24, Attach cursor to workspace #1.
+# Note that this clears the tabs so it must be done by tset before
+# it sets the tabs.
+#
+hp2626-s|hp 2626 using only 23 lines,
+ eslok, hs,
+ lines#23,
+ fsl=\E&d@\E&w7f2p1I\E&w4f1I,
+ is1=\E&q3t0{0H \E&w0f115n1I \E&w0f1n2I \E&w2f1i0d0u22l0S \E&w2f2i0d23u23l0S \E&w7f2p1I \r,
+ tsl=\E&w7f2p2I\E&w4f2I\r\EK\E&a%p1%dC,
+ use=hp2626,
+# Force terminal back to 24 lines after being 23.
+hp2626-ns|hp 2626 using all 24 lines,
+ is1=\E&q3t0{0H \E&w0f118n1I \E&w0f1n2I \E&w2f1i0d0u23l0S \E&w3f2I \E&w7f2p1I \r, use=hp2626,
+# Various entries useful for small windows on 2626.
+hp2626-12|hewlett-packard 2626 12 lines,
+ lines#12, use=hp2626,
+hp2626-12x40|hewlett-packard 2626 12 lines 40 columns,
+ cols#40, lines#12, use=hp2626,
+hp2626-x40|hewlett-packard 2626 40 columns,
+ cols#40, use=hp2626,
+hp2626-12-s|hewlett-packard 2626 11 lines plus status,
+ lines#11, use=hp2626-s,
+
+#
+# hp2627 color tubes from University of Wisconsin
+#
+hp2627a-rev|hp 2627 with reverse video colors,
+ cr=^M, cud1=^J, ht=^I, ind=^J,
+ is2=\E&v0m1a0b0c1x1y1z1i0a0b1c1x1y1z0i0S\E&j@\r\E3\r,
+ kbs=^H, kcub1=^H, kcud1=^J, nel=^M^J, rmul=\E&v0S\E&d@,
+ smul=\E&dD\E&v1S,
+ use=hp2621-nl,
+hp2627a|hp 2627 color terminal with no labels,
+ cr=^M, cud1=^J, ht=^I, ind=^J,
+ is2=\E&v0m1a1b0c1i0a1b1c2i1a0b0c0i0S\E&j@\r\E3\r,
+ kbs=^H, kcub1=^H, kcud1=^J, nel=^M^J, rmso=\E&v0S,
+ rmul=\E&v0S\E&d@, smso=\E&v2S, smul=\E&dD\E&v1S,
+ use=hp2621-nl,
+hp2627c|hp 2627 color (cyan) terminal with no labels,
+ cr=^M, cud1=^J, ht=^I, ind=^J,
+ is2=\E&v0m1a0b0c2i1a1b0c1i0a1b1c0i0S\E&j@\r\E3\r,
+ kbs=^H, kcub1=^H, kcud1=^J, nel=^M^J,
+ use=hp2627a,
+
+# hp2640a doesn't have the Y cursor addressing feature, and C is
+# memory relative instead of screen relative, as we need.
+#
+hp2640a|hp 2640a,
+ cup@, rmkx@, smkx@, use=hp2645,
+
+hp2640b|hp2644a|hp 264x series,
+ rmkx@, smkx@, use=hp2645,
+
+# (hp2641a: removed unknown :gu: -- esr)
+hp2641a|hp2645a|hp2647a|HP 264?A series BRL entry,
+ am, da, db, mir, xhp,
+ cols#80, lines#24,
+ bel=^G, clear=\EH\EJ, cr=^M, cub1=^H, cud1=^J, cuf1=\EC,
+ cup=\E&a%p2%2dc%p1%2dY, cuu1=\EA, dch1=\EP, dl1=\EM,
+ ed=\EJ, el=\EK, hpa=\E&a%p1%2dC, ht=^I,
+ if=/usr/share/tabset/std, il1=\EL, ind=^J,
+ is2=\EE$<500/>, kbs=^H, kcub1=^H, kcud1=^J, nel=^M^J,
+ rmir=\ER, rmso=\E&d@, smir=\EQ, smso=\E&dB,
+ vpa=\E&a%p1%2dY,
+
+# This terminal should be used at 4800 baud or less. It needs padding for
+# plain characters at 9600, I guessed at an appropriate cr delay. It really
+# wants ^E/^F handshaking, but that doesn't work well even if you write
+# software to support it.
+hp2645|hp45|HP 2645 series,
+ pb#9600,
+ blink=\E&dA, cr=\r$<20>, dim=\E&dH, kctab=\E2, kcub1=\ED,
+ kcud1=\EB, kcuf1=\EC, kcuu1=\EA, kdch1=\EP, kdl1=\EM,
+ ked=\EJ, kel=\EK, khome=\Eh, khts=\E1, kich1=\EQ, kil1=\EL,
+ kind=\ES, knp=\EU, kpp=\EV, kri=\ET, krmir=\ER, rev=\E&dB,
+ rmkx=\E&s0A,
+ sgr=\E&d%{64}%?%p1%t%{66}%|%;%?%p2%t%{68}%|%;%?%p3%t%{66}%|%;%?%p4%t%{65}%|%;%?%p5%t%{72}%|%;%?%p6%t%{66}%|%;%c,
+ sgr0=\E&d@, smkx=\E&s1A, smul=\E&dD,
+ use=hpgeneric,
+# You should use this terminal at 4800 baud or less.
+hp2648|hp2648a|HP 2648a graphics terminal,
+ clear=\EH\EJ$<50>, cup=\E&a%p2%dc%p1%dY$<20>,
+ dch1=\EP$<7>, ip=$<5>,
+ use=hp2645,
+
+# The HP 150 terminal is a fairly vanilla HP terminal, with the
+# clreol standout problem. It also has graphics capabilities and
+# a touch screen, which we don't describe here.
+hp150|hewlett packard Model 150,
+ use=hp2622,
+
+# HP 2382a terminals, "the little ones." They don't have any
+# alternate character set support and sending out ^N/^O will
+# leave the screen blank.
+hp2382a|hp2382|hewlett packard 2382a,
+ da, db,
+ lh#1, lm#48,
+ acsc@,
+ pln=\E&f0a%p1%dk%p2%l%Pa%?%ga%t%ga%d%e1%;d0L%?%ga%!%t %;%p2%s,
+ rmacs@,
+ sgr=\E&d%{0}%Pa%?%p4%t%{1}%ga%+%Pa%;%?%p1%p3%|%p6%|%t%{2}%ga%+%Pa%;%?%p2%p6%|%t%{4}%ga%+%Pa%;%?%p1%p5%|%t%{8}%ga%+%Pa%;%?%p7%t%?%ga%ts%ga%{64}%+%e%{83}%;%e%?%ga%t%ga%{64}%+%e%{64}%;%;%c,
+ sgr0=\E&d@, smacs@,
+ use=hp+labels, use=scrhp,
+
+hp2621-a|hp2621a-a|hp2621 with fn as arrows,
+ use=hp+pfk+arrows, use=hp2621-fl,
+
+# newer hewlett packard terminals
+
+newhpkeyboard|generic entry for HP extended keyboard,
+ kbs=^H, kcbt=\Ei, kclr=\EJ, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kdch1=\EP, kdl1=\EM, ked=\EJ, kel=\EK, khome=\Eh,
+ kich1=\EQ, kil1=\EL, kind=\ET, kll=\EF, knp=\EU, kpp=\EV,
+ kri=\ES, krmir=\ER, rmkx=\E&s0A, smkx=\E&s1A,
+ use=hp+pfk-cr,
+
+newhp|generic entry for new hewlett packard terminals,
+ am, bw, mir, xhp, xon,
+ cols#80, lines#24, pb#4800,
+ acsc=2[3@4>5I9(\:'JSKWLQMAO#P$Q;R!S"T1U2V4W3X\:Y+Z*dHjGkTlRmFn/q\,t5u6v8w7x.,
+ bel=^G, blink=\E&dA, bold=\E&dF, cbt=\Ei, cr=^M, cub1=^H,
+ cud1=^J, cuf1=\EC, cuu1=\EA, dch1=\EP$<2>, dim=\E&dH,
+ dl1=\EM, ed=\EJ, el=\EK, ht=\011$<2>, hts=\E1, il1=\EL, ind=^J,
+ invis=\E&dS, ip=$<2>, is1=\E&jB$<8>, nel=^M^J,
+ pfkey=\E&f0a%p1%dk0d%p2%l%dL%p2%s,
+ pfloc=\E&f1a%p1%dk0d%p2%l%dL%p2%s,
+ pfx=\E&f2a%p1%dk0d%p2%l%dL%p2%s, rev=\E&dB, ri=\ET,
+ rmacs=^O, rmir=\ER, rmso=\E&d@, rmul=\E&d@, rs1=\Eg,
+ sgr=\E&d%{0}%Pa%?%p4%t%{1}%ga%+%Pa%;%?%p1%p3%|%p6%|%t%{2}%ga%+%Pa%;%?%p2%p6%|%t%{4}%ga%+%Pa%;%?%p1%p5%|%t%{8}%ga%+%Pa%;%?%p7%t%?%ga%ts%ga%{64}%+%e%{83}%;%e%?%ga%t%ga%{64}%+%e%{64}%;%;%c%?%p9%t\016%e\017%;,
+ sgr0=\E&d@\017, smacs=^N, smir=\EQ, smso=\E&dJ, smul=\E&dD,
+ tbc=\E3,
+ use=newhpkeyboard,
+
+memhp|memory relative addressing for new HP ttys,
+ vt#6,
+ clear=\EH\EJ$<40>, cub=\E&a-%p1%dC, cud=\E&a+%p1%dR,
+ cuf=\E&a+%p1%dC, cup=\E&a%p1%dr%p2%dC, cuu=\E&a-%p1%dR,
+ home=\EH, hpa=\E&a%p1%dC, ll=\E&a23R\r,
+ mrcup=\E&a%p1%dr%p2%dC, vpa=\E&a%p1%dR, use=newhp,
+
+scrhp|screen relative addressing for new HP ttys,
+ clear=\E&a0c0Y\EJ$<40>, cub=\E&a-%p1%dC,
+ cud=\E&a+%p1%dR, cuf=\E&a+%p1%dC,
+ cup=\E&a%p1%dy%p2%dC$<10>, cuu=\E&a-%p1%dR,
+ home=\E&a0y0C, hpa=\E&a%p1%dC, ll=\E&a0y0C\EA,
+ mrcup=\E&a%p1%dr%p2%dC, vpa=\E&a%p1%dY, use=newhp,
+
+# (hp+labels: added label values from a BRL termcap -- esr)
+hp+labels|"standard" label info for new HP ttys,
+ lh#2, lw#8, nlab#8,
+ lf0=f1, lf1=f2, lf2=f3, lf3=f4, lf4=f5, lf5=f6, lf6=f7, lf7=f8,
+ pln=\E&f2a%p1%dk%p2%l%Pa%?%ga%t%ga%d%e1%;d0L%?%ga%!%t %;%p2%s,
+ rmln=\E&j@, smln=\E&jB,
+
+hp+printer|"standard" printer info for HP ttys,
+ ff=\E&p4u0C, mc0=\EH\E&p4dF, mc4=\E&p13C, mc5=\E&p11C,
+
+
+# The new hp2621b is kind of a cross between the old 2621 and the
+# new 262x series of machines. It has dip-switched options.
+# The firmware has a bug in it such that if you give it a null
+# length label, the following character is eaten!
+hp2621b|hp 2621b with old style keyboard,
+ lh#1, lm#48, lw#8, nlab#8,
+ kcub1=\ED, kcud1=\EB, kcuf1=\EC, kcuu1=\EA, khome=\Eh,
+ kind=\ET, kll=\EF, kri=\ES,
+ pln=\E&f0a%p1%dk%p2%l%Pa%?%ga%t%ga%d%e1%;d3L%?%ga%!%t%{32}%c%;%p2%s\E%{111}%p1%+%c\r,
+ smln=\E&jB,
+ use=hp2621,
+
+hp2621b-p|hp 2621b with printer,
+ use=hp+printer, use=hp2621b,
+
+# hp2621b - new 2621b with new extended keyboard
+# these are closer to the new 26xx series than the other 2621b
+hp2621b-kx|hp 2621b with extended keyboard,
+ use=newhpkeyboard, use=hp2621b,
+
+hp2621b-kx-p|hp 2621b with new keyboard & printer,
+ use=hp+printer, use=hp2621b-kx,
+
+# Some assumptions are made in the following entries.
+# These settings are NOT set up by the initialization strings.
+#
+# Port Configuration
+# RecvPace=Xon/Xoff XmitPace=Xon/Xoff StripNulDel=Yes
+#
+# Terminal Configuration
+# InhHndShk(G)=Yes InhDC2(H)=Yes
+# XmitFnctn(A)=No InhEolWrp=No
+#
+#
+# Hp 2622a & hp2623a display and graphics terminals
+#
+hp2622|hp2622a|hp 2622,
+ da, db,
+ lm#0, pb#19200,
+ is2=\E&dj@\r, use=hp+pfk+cr, use=hp+labels, use=scrhp,
+
+# The 2623 is a 2622 with extra graphics hardware.
+hp2623|hp2623a|hp 2623,
+ use=hp2622,
+
+hp2624b-p|hp2624b-4p-p|hewlett packard 2624 B with printer,
+ use=hp+printer, use=hp2624,
+
+# The hewlett packard B can have an optional extra 6 pages of memory.
+hp2624-10p|hp2624a-10p|hp2624b-10p|hewlett packard 2624 B w/ 10 pages of memory,
+ lm#240, use=hp2624,
+
+hp2624b-10p-p|hewlett packard 2624 B w/ extra memory & printer,
+ lm#240, use=hp2624b-p,
+
+# Color manipulations for HP terminals
+hp+color|hp with colors,
+ ccc,
+ colors#16, ncv#17, pairs#7,
+ initp=\E&v%?%p2%{1000}%=%t1%e.%p2%d%;a%?%p3%{1000}%=%t1%e.%p3%d%;b%?%p4%{1000}%=%t1%e.%p4%d%;c%?%p5%{1000}%=%t1%e.%p5%d%;x%?%p6%{1000}%=%t1%e.%p6%d%;y%?%p7%{1000}%=%t1%e.%p7%d%;z%p1%dI,
+ oc=\E&v0m1a1b1c0I\E&v1a1I\E&v1b2I\E&v1a1b3I\E&v1c4I\E&v1a1c5I\E&v1b1c6I\E&v1x1y7I,
+ op=\E&v0S, scp=\E&v%p1%dS,
+
+# <is2> sets the screen to be 80 columns wide
+hp2397a|hp2397|hewlett packard 2397A color terminal,
+ is2=\E&w6f80X,
+ use=memhp, use=hp+labels, use=hp+color,
+
+# HP 700/44 Setup parameters:
+# Terminal Mode HP-PCterm
+# Inhibit Auto Wrap NO
+# Status Line Host Writable
+# PC Character Set YES
+# Twenty-Five Line Mode YES
+# XON/XOFF @128 or 64 (sc)
+# Keycode Mode NO or YES (sc)
+# Backspace Key BS or BS/DEL
+#
+# <is2> sets pcterm; autowrap; 25 lines; pc char set; prog DEL key;
+# \E\\? does not turn off keycode mode
+# <smsc> sets alternate start/stop; keycode on
+hpansi|hp700|hewlett packard 700/44 in HP-PCterm mode,
+ am, eo, xenl, xon,
+ cols#80, lines#25,
+ acsc=j\331k\277l\332m\300n\305q\304t\303u\264v\301w\302x\263,
+ bel=^G, cbt=\E[Z, civis=\E[?25l, clear=\E[2J\E[H,
+ cnorm=\E[?25h, cr=^M, cub1=\E[D, cud1=\E[B, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch1=\E[P, dl1=\E[M,
+ ed=\E[J, el=\E[K, home=\E[H, ht=^I, ich1=\E[@, il1=\E[L,
+ ind=^J,
+ is2=\E[44"p\E[?7h\E[>10h\E[>12h\EP1;1|3/7F\E\\,
+ kbs=^H, kcbt=\E[Z, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C,
+ kcuu1=\E[A, kend=\E[4~, kf1=\E[17~, kf10=\E[28~,
+ kf2=\E[18~, kf3=\E[19~, kf4=\E[20~, kf5=\E[21~, kf6=\E[23~,
+ kf7=\E[24~, kf8=\E[25~, kf9=\E[26~, khome=\E[1~, knp=\E[6~,
+ kpp=\E[5~, rmam=\E[?7l,
+ rmsc=\E[>11l\EP1**x0/11;1/13\E[m\E\\, rmso=\E[m,
+ rmul=\E[m, sgr0=\E[m, smam=\E[?7h,
+ smsc=\E[>11h\EPO**x0/65;1/67\E\\$<250>, smso=\E[7m,
+ smul=\E[4m, xoffc=g, xonc=e,
+#
+# (hp2392: copied <rmir> here from hpex -- esr)
+hp2392|239x series,
+ cols#80,
+ cbt=\Ei, cup=\E&a%p1%dy%p2%dC, kf1=\Ep\r, kf2=\Eq\r,
+ kf3=\Er\r, kf4=\Es\r, kf5=\Et\r, kf6=\Eu\r, kf7=\Ev\r,
+ kf8=\Ew\r, khome=\Eh, kind=\EU, knp=\Eu, kpp=\Ev, kri=\EV,
+ rmir=\ER, rmul=\E&d@, smir=\EQ, smul=\E&dD, vpa=\E&a%p1%dY,
+ use=hpsub,
+
+hpsub|hp terminals -- capability subset,
+ am, da, db, mir, xhp, xon,
+ lines#24,
+ bel=^G, clear=\EH\EJ, cr=^M, cub1=^H, cud1=\EB, cuf1=\EC,
+ cuu1=\EA, dch1=\EP, dl1=\EM, ed=\EJ, el=\EK, hpa=\E&a%p1%dC,
+ ht=^I, if=/usr/share/tabset/stdcrt, il1=\EL, ind=^J,
+ is2=\E&s1A\E<\E&k0\\, kbs=^H, kcub1=\ED, kcud1=\EB,
+ kcuf1=\EC, kcuu1=\EA, khome=\Eh, rmkx=\E&s0A, rmso=\E&d@,
+ sgr0=\E&d@, smkx=\E&s1A, smso=\E&dB,
+
+# hpex:
+# May be used for most 24 x 80 hp terminals,
+# but has no padding added, so may allow runover in some terminals at high
+# baud rates. Will not work for hp2640a or hp2640b terminals, hp98x6 and
+# hp98x5 terminal emulators or hp98x6 consoles.
+# Adds xy-cursor addressing, vertical cursor addressing, home,
+# last line, and underline capabilities.
+#
+# (hpex: removed memory-lock capabilities ":ml=\El:mu=\Em:",
+# moved <rmir> here from hpsub -- esr)
+hpex|hp extended capabilites,
+ cr=^M, cud1=^J, cup=\E&a%p1%dy%p2%dC, ht=^I, ind=^J, kbs=^H,
+ kcub1=^H, kcud1=^J, nel=^M^J, rmir=\ER, rmul=\E&d@, smir=\EQ,
+ smul=\E&dD, vpa=\E&a%p1%dY,
+ use=hpsub,
+
+# From: Ville Sulko <Ville.Sulko@bip.atk.tpo.fi>, 05 Aug 1996
+hp2|hpex2|hewlett-packard extended capabilities newer version,
+ am, da, db, mir, xhp,
+ cols#80, lh#2, lines#24, lm#0, lw#8, nlab#8, xmc#0,
+ bel=^G, clear=\E&a0y0C\EJ, cr=^M, cub1=^H, cud1=\EB,
+ cuf1=\EC, cup=\E&a%p1%dy%p2%dC, cuu1=\EA, dch1=\EP,
+ dl1=\EM, ed=\EJ, el=\EK, hpa=\E&a%p1%dC, ht=^I, hts=\E1,
+ il1=\EL, ind=^J, kbs=^H, kclr=\EJ, kctab=\E2, kcub1=\ED,
+ kcud1=\EB, kcuf1=\EC, kcuu1=\EA, kdch1=\EP, kdl1=\EM,
+ ked=\EJ, kel=\EK, kf1=\Ep, kf2=\Eq, kf3=\Er, kf4=\Es, kf5=\Et,
+ kf6=\Eu, kf7=\Ev, kf8=\Ew, khome=\Eh, khts=\E1, kich1=\EQ,
+ kil1=\EL, kind=\ES, kll=\EF, knp=\EU, kpp=\EV, kri=\ET,
+ krmir=\ER, ktbc=\E3, meml=\El, memu=\Em,
+ pfkey=\E&f%p1%dk%p2%l%dL%p2%s,
+ pfloc=\E&f1a%p1%dk%p2%l%dL%p2%s,
+ pfx=\E&f2a%p1%dk%p2%l%dL%p2%s,
+ pln=\E&f%p1%dk%p2%l%dd0L%p2%s, rmir=\ER, rmkx=\E&s0A,
+ rmln=\E&j@, rmso=\E&d@, rmul=\E&d@,
+ sgr=\E&d%?%p7%t%{115}%c%;%p1%p3%|%p6%|%{2}%*%p2%{4}%*%+%p4%+%p5%{8}%*%+%{64}%+%c%?%p9%t%'\016'%c%e%'\017'%c%;,
+ sgr0=\E&d@, smir=\EQ, smkx=\E&s1A, smln=\E&jB, smso=\E&dB,
+ smul=\E&dD, tbc=\E3, vpa=\E&a%p1%dY,
+
+# HP 236 console
+# From: <ddavis@ic.berkeley.edu>
+hp236|hp236 internal terminal emulator,
+ am,
+ cols#80, lines#24,
+ clear=\EF, cnorm=\EDE, cub1=^H,
+ cup=\EE%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, cvvis=\EDB,
+ dch1=\EJ, dl1=\EH, el=\EK, ich1=\EI, il1=\EG, rmso=\ECI,
+ sgr0=\ECI, smso=\EBI,
+
+# This works on a hp300 console running Utah 4.3 BSD
+# From: Craig Leres <leres@okeeffe.berkeley.edu>
+hp300h|HP Catseye console,
+ am, da, db, mir, xhp,
+ cols#128, lines#51, lm#0, xmc#0,
+ bel=^G, cbt=\Ei, clear=\E&a0y0C\EJ, cr=^M, cub1=^H, cud1=\EB,
+ cuf1=\EC, cup=\E&a%p1%dy%p2%dC, cuu1=\EA, dch1=\EP,
+ dl1=\EM, ed=\EJ, el=\EK, hpa=\E&a%p1%dC, ht=^I,
+ if=/usr/share/tabset/stdcrt, il1=\EL, ind=^J, kbs=^H,
+ kcub1=\ED, kcud1=\EB, kcuf1=\EC, kcuu1=\EA, khome=\Eh,
+ rmir=\ER, rmkx=\E&s0A, rmso=\E&d@, rmul=\E&d@, sgr0=\E&d@,
+ smir=\EQ, smkx=\E&s1A, smso=\E&dB, smul=\E&dD, tbc=\E3,
+ vpa=\E&a%p1%dY,
+# From: Greg Couch <gregc@ernie.berkeley.edu>
+hp9837|hp98720|hp98721|HP 9000/300 workstations,
+ am, da, db, mir, xhp,
+ cols#128, it#8, lines#46, lm#0,
+ bel=^G, cbt=\Ei, clear=\E&a0y0C\EJ, cub1=^H, cud1=\EB,
+ cuf1=\EC, cup=\E&a%p1%dy%p2%dC, cuu1=\EA, dch1=\EP,
+ dl1=\EM, ed=\EJ, el=\EK, hpa=\E&a%p1%dC, ht=^I, hts=\E1,
+ il1=\EL, ind=^J, is2=\E&v0m1b0i&j@, kbs=^H, kcub1=\ED,
+ kcud1=\EB, kcuf1=\EC, kcuu1=\EA, kdch1=\EP, kdl1=\EM,
+ ked=\EJ, kel=\EK, khome=\Eh, kich1=\EQ, kil1=\EL, knp=\EU,
+ kpp=\EV, rmir=\ER, rmkx=\E&s0A, rmso=\E&v0S, rmul=\E&d@,
+ sgr0=\E&d@, smir=\EQ, smkx=\E&s1A, smso=\E&v5S, smul=\E&dD,
+ tbc=\E3, vpa=\E&a%p1%dY,
+# HP 9845 desktop computer from BRL
+# (hp9845: removed unknown capability :gu: -- esr)
+hp9845|HP 9845,
+ am, da, db, eo, mir, xhp,
+ cols#80, lines#21,
+ clear=\EH\EJ, cuf1=\EC, cup=\E&a%p2%2dc%p1%2dY, cuu1=\EA,
+ dch1=\EP, dl1=\EM, ed=\EJ, el=\EK,
+ if=/usr/share/tabset/std, il1=\EL, rmir=\ER, rmso=\E&d@,
+ smir=\EQ, smso=\E&dB,
+# From: Charles A. Finnell of MITRE <finnell@mitre.org>, developed 07SEP90
+# (hp98550: replaced /usr/share/tabset/9837 with std because <it#8>,<hts=\E1>;
+# added empty <acsc> to avoid warnings re <smacs>/<rmacs> --esr)
+hp98550|hp98550a|HP 9000 Series 300 color console,
+ am, da, db, mir, xhp,
+ cols#128, it#8, lines#49, lm#0,
+ acsc=, bel=^G, blink=\E&dA, bold=\E&dJ, cbt=\Ei, civis=\E*dR,
+ clear=\EH\EJ, cnorm=\E*dQ, cr=^M, cub1=^H, cud1=^J, cuf1=\EC,
+ cup=\E&a%p1%dy%p2%dC, cuu1=\EA, dch1=\EP, dim=\E&dH,
+ dl1=\EM, ed=\EJ, el=\EK, hpa=\E&a%p1%dC, ht=^I, hts=\E1,
+ if=/usr/share/tabset/std, il1=\EL, ind=^J, invis=\E&ds,
+ kbs=^H, kclr=\EJ, kctab=\E2, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kdch1=\EP, kdl1=\EM, ked=\EJ, kel=\EK, kf1=\Ep,
+ kf2=\Eq, kf3=\Er, kf4=\Es, kf5=\Et, kf6=\Eu, kf7=\Ev, kf8=\Ew,
+ khome=\Eh, khts=\E1, kich1=\EQ, kil1=\EL, kind=\ES, kll=\EF,
+ knp=\EU, kpp=\EV, kri=\ET, krmir=\ER, ktbc=\E3, rev=\E&dJ,
+ rmacs=^O, rmir=\ER, rmkx=\E&s0A, rmso=\E&d@, rmul=\E&d@,
+ sgr0=\E&d@, smacs=^N, smir=\EQ, smkx=\E&s1A, smso=\E&dJ,
+ smul=\E&dD, tbc=\E3, vpa=\E&a%p1%dY,
+# From: Victor Duchovni <vic@fine.princeton.edu>
+# (hp700-wy: removed obsolete ":nl=^J:";
+# replaced /usr/share/tabset/hp700-wy with std because <it#8>,<hts=\E1> -- esr)
+hp700-wy|HP700/41 emulating wyse30,
+ am, bw, mir, msgr,
+ cols#80, it#8, lines#24, xmc#1,
+ cbt=\EI, clear=^Z, cr=^M, cub1=^H, cud1=^V, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, ed=\EY, el=\ET$<10/>, home=^^, ht=^I, hts=\E1,
+ if=/usr/share/tabset/stdcrt, il1=\EE$<0.7*/>,
+ is1=\E~"\EC\Er\E(\EG0\003\E`9\E`1, kbs=\177, kcbt=\EI,
+ kclr=^Z, kcub1=^H, kcud1=^V, kcuf1=^L, kcuu1=^K, ked=\EY,
+ kel=\ET, khome=^^, khts=\EI, kich1=\Eq, krmir=\Er, ll=^^^K,
+ ri=\Ej, rmir=\Er, rmso=\EG0$<10/>, rmul=\EG0$<10/>,
+ sgr0=\EG0$<10/>, smir=\Eq, smso=\EG4$<10/>,
+ smul=\EG8$<10/>, tbc=\E0, vpa=\E[%p1%{32}%+%c,
+# (hp70092: added empty <acsc> to avoid warnings re <smacs>/<rmacs> --esr)
+hp70092|hp70092a|hp70092A|HP 700/92,
+ am, da, db, xhp,
+ cols#80, lh#2, lines#24, lm#0, lw#8, nlab#8,
+ acsc=, bel=^G, blink=\E&dA, bold=\E&dB, cbt=\Ei,
+ clear=\E&a0y0C\EJ, cr=^M, cub1=^H, cud1=\EB, cuf1=\EC,
+ cup=\E&a%p1%dy%p2%dC, cuu1=\EA, dch1=\EP, dim=\E&dH,
+ dl1=\EM, el=\EK, hpa=\E&a%p1%dC, ht=^I, hts=\E1, il1=\EL,
+ kbs=^H, kclr=\EJ, kctab=\E2, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kdch1=\EP, kdl1=\EM, ked=\EJ, kel=\EK, kf1=\Ep,
+ kf2=\Eq, kf3=\Er, kf4=\Es, kf5=\Et, kf6=\Eu, kf7=\Ev, kf8=\Ew,
+ khome=\Eh, khts=\E1, kich1=\EQ, kil1=\EL, kind=\ES, kll=\EF,
+ knp=\EU, kpp=\EV, kri=\ET, krmir=\ER, ktbc=\E3, rev=\E&dB,
+ ri=\ET, rmacs=^O, rmir=\ER, rmkx=\E&s0A, rmln=\E&j@,
+ rmso=\E&d@, rmul=\E&d@, sgr0=\E&d@, smacs=^N, smir=\EQ,
+ smkx=\E&s1A, smln=\E&jB, smso=\E&dJ, smul=\E&dD, tbc=\E3,
+ vpa=\E&a%p1%dY,
+
+bobcat|sbobcat|HP 9000 model 300 console,
+ am, da, db, mir, xhp,
+ cols#128, it#8, lines#47, xmc#0,
+ cbt=\Ei, clear=\EH\EJ, cr=^M, cub1=^H, cud1=\EB, cuf1=\EC,
+ cup=\E&a%dy%dC$<6/>, cuu1=\EA, dch1=\EP, dl1=\EM$<10*/>,
+ ed=\EJ, el=\EK, hpa=\E&a%dC$<6/>, ht=^I, il1=\EL$<10*/>,
+ ind=^J, kbs=^H, kcub1=\ED, kcud1=\EB, kcuf1=\EC, kcuu1=\EA,
+ khome=\Eh, nel=^M^J, rmir=\ER, rmkx=\E&s0A, rmso=\E&d@,
+ rmul=\E&d@, sgr0=\E&d@, smir=\EQ, smkx=\E&s1A, smso=\E&dB,
+ smul=\E&dD, vpa=\E&a%dY$<6/>,
+gator-t|HP 9000 model 237 emulating extra-tall AAA,
+ lines#94, use=gator,
+gator|HP 9000 model 237 emulating AAA,
+ bw, km, mir, ul,
+ cols#128, it#8, lines#47,
+ bel=^G, cbt=\E[Z, clear=\E[H\E[J, cr=^M, cub1=^H, cud1=^J,
+ cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\EM,
+ dch=\E[%p1%dP$<4/>, dch1=\E[P, dl=\E[%p1%dM$<1*/>,
+ dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, hpa=\E[%i%p1%d`,
+ ht=^I, ich=\E[%p1%d@$<4/>, ich1=\E[@, il=\E[%p1%dL$<1*/>,
+ il1=\E[L, kbs=^H, kcub1=^H, kcud1=^J, nel=^M^J,
+ rep=%p1%c\E[%p2%db$<1*/>, rev=\E[7m, rmso=\E[m,
+ rmul=\E[m, sgr0=\E[m, smso=\E[7m, smul=\E[4m,
+gator-52|HP 9000 model 237 emulating VT52,
+ cols#128, lines#47, use=vt52,
+gator-52t|HP 9000 model 237 emulating extra-tall VT52,
+ lines#94, use=gator-52,
+
+#### Honeywell-Bull
+#
+# From: Michael Haardt <michael@gandalf.moria> 11 Jan 93
+#
+
+# Honeywell Bull terminal. Its cursor and function keys send single
+# control characters and it has standout/underline glitch. Most programs
+# do not like these features/bugs. Visual bell is realized by flashing the
+# "keyboard locked" LED.
+dku7003-dumb|Honeywell Bull DKU 7003 dumb mode,
+ cols#80, lines#25,
+ clear=^]^_, cr=^M, cub1=^Y, cud1=^K, cuf1=^X,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=^Z, ed=^_, el=\E[K,
+ flash=\E[2h\E[2l, home=^], ht=^I, ind=^J, kbs=^H, kcub1=^Y,
+ kcud1=^K, kcuf1=^X, kcuu1=^Z, khome=^], nel=^M^J,
+dku7003|Honeywell Bull DKU 7003 all features described,
+ msgr,
+ xmc#1,
+ blink=\E[5m, bold=\E[7m, dim=\E[2m, rev=\E[7m, rmso=\E[m,
+ rmul=\E[m, sgr0=\E[m, smso=\E[7m, smul=\E[4m,
+ use=dku7003-dumb,
+
+#### Lear-Siegler (adm)
+#
+# These guys are long since out of the terminals business, but
+# in 1995 many current terminals still have an adm type as one of their
+# emulations (usually their stupidest, and usually labeled adm3, though
+# these `adm3' emulations normally have adm3a+ capabilities).
+#
+# WARNING: Some early ADM terminals (including the ADM3 and ADM5) had a
+# `diagnostic feature' that sending them a ^G while pin 22 (`Ring Indicator')
+# was being held to ground would trigger a send of the top line on the screen.
+# A quick fix might be to drop back to a cheesy 4-wire cable with pin 22
+# hanging in the air. (Thanks to Eric Fischer, <eric@fudge.uchicago.edu>,
+# for clearing up this point.)
+
+adm1a|adm1|lsi adm1a,
+ am,
+ cols#80, lines#24,
+ bel=^G, clear=\E;$<1>, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, home=^^,
+ ind=^J,
+adm2|lsi adm2,
+ am,
+ cols#80, lines#24,
+ bel=^G, clear=\E;, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, ed=\EY, el=\ET, home=^^, ich1=\EQ, il1=\EE, ind=^J,
+ kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, khome=^^,
+# (adm3: removed obsolete ":ma=^K^P:" -- esr)
+adm3|lsi adm3,
+ am,
+ cols#80, lines#24,
+ bel=^G, clear=^Z, cr=^M, cub1=^H, cud1=^J, ind=^J,
+# The following ADM-3A switch settings are assumed for normal operation:
+# SPACE U/L_DISP CLR_SCRN 24_LINE
+# CUR_CTL LC_EN AUTO_NL FDX
+# Other switches may be set for operator convenience or communication
+# requirements. I recommend
+# DISABLE_KB_LOCK LOCAL_OFF 103 202_OFF
+# ETX_OFF EOT_OFF
+# Most of these terminals required an option ROM to support lower case display.
+# Open the case and look at the motherboard; if you see an open 24-pin DIP
+# socket, you may be out of luck.
+#
+# (adm3a: some capabilities merged in from BRl entry -- esr)
+adm3a|lsi adm3a,
+ am,
+ cols#80, lines#24,
+ bel=^G, clear=\032$<1/>, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, home=^^,
+ ind=^J, kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, rs1=^N,
+adm3a+|adm3a plus,
+ kbs=^H, use=adm3a,
+# (adm5: removed obsolete ":ma=^Hh^Jj^Kk^Ll^^H:" & duplicate ":do=^J:" -- esr)
+adm5|lsi adm5,
+ xmc#1,
+ bel=^G, cr=^M, cud1=^J, ed=\EY, el=\ET, kbs=^H, khome=^^,
+ rmso=\EG, smso=\EG,
+ use=adm3a+,
+# A lot of terminals other than adm11s use these. Wherever you see
+# use=adm+sgr with some of its capabilities disabled, try the
+# disabled ones. They may well work but not have been documented or
+# expressed in the using entry. We'd like to cook up an <sgr> but the
+# <rmacs>/<smacs> sequences of the using entries vary too much.
+adm+sgr|adm style highlight capabilities,
+ invis=\EG1, rev=\EG4, rmso=\EG0, rmul=\EG0, sgr0=\EG0,
+ smso=\EG4, smul=\EG8,
+# LSI ADM-11 from George William Hartwig, Jr. <geo@BRL-TGR.ARPA> via BRL
+# Status line additions from Stephen J. Muir <stephen%comp.lancs.ac.uk@ucl-cs>
+# <khome> from <stephen%comp.lancs.ac.uk@ucl-cs.arpa>. <clear> could also
+# be ^Z, according to his entry.
+# (adm11: <smul>=\EG4 was obviously erroneous because it also said
+# <rev>=\EG4. Looking at other ADMs confirms this -- esr)
+adm11|LSI ADM-11,
+ am, hs,
+ cols#80, lines#24,
+ bel=^G, blink=\EG2, clear=\E*, cr=^M, cub1=^H, cud1=^J,
+ cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
+ dsl=\Eh, ed=\EY, el=\ET, fsl=\E(\r, home=^^, ht=^I, kbs=^H,
+ kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, kf1=^A@\r, kf2=^AA\r,
+ kf3=^AB\r, kf4=^AC\r, kf5=^AD\r, kf6=^AE\r, kf7=^AF\r,
+ kf8=^AG\r, khome=^^, nel=^M^J, tsl=\EF\E),
+ use=adm+sgr,
+# From: Andrew Scott Beals <bandy@lll-crg.ARPA>
+# Corrected by Olaf Siebert <rhialto@polder.ubc.kun.nl>, 11 May 1995
+# Supervisor mode info by Ari Wuolle, <awuolle@delta.hut.fi>, 27 Aug 1996
+# (adm12: removed obsolete ":kn:ma=j^Jk^P^K^Pl ^R^L^L :". This formerly had
+# <is2>=\Eq but that looked wrong; this <is2> is from Dave Yost <esquire!yost>
+# via BRL. That entry asserted <xmc#1>, but I've left that out because
+# neither earlier nor later ADMSs have it -- esr)
+#
+# You will need to get into the supervisor setup before you can set
+# baudrate etc. for your ADM-12+. Press Shift-Ctrl-Setup and you should
+# see a lot more setup options.
+#
+# While in supervisor setup you can also use following codes:
+#
+# Ctrl-P Personality character selections (configure for example what
+# arrow keys send, if I recall correctly)
+# Ctrl-T tabs 1-80 use left&right to move and up to set and
+# Ctrl-V tabs 81-158 down to clear tab. Shift-Ctrl-M sets right margin at cursor
+# Ctrl-B Binary setup (probably not needed. I think that everything can
+# be set using normal setup)
+# Ctrl-A Answerback mode (enter answerback message)
+# Ctrl-U User friendly mode (normal setup)
+# Ctrl-D Defaults entire setup and function keys from EPROM tables
+# Ctrl-S Save both setup and functions keys. Takes from 6 to 10 seconds.
+# Ctrl-R Reads both setup and functions keys from NVM.
+# Shift-Ctrl-X Unlock keyboard and cancel received X-OFF status
+#
+# ADM-12+ supports hardware handshaking, but it is DTR/CTS as opposed to
+# RTS/CTS used nowadays with virtually every modem and computer. 19200
+# bps works fine with hardware flow control.
+#
+# The following null-modem cable should fix this and enable you to use
+# RTS/CTS handshaking (which Linux supports, use CRTSCTS setting). Also
+# set ADM-12+ for DTR handshaking from supervisor setup.
+#
+# PC Serial ADM-12+
+# -------- -------
+# 2 - 3
+# 3 - 2
+# 4 - 5
+# 5 - 20
+# 6,8 - 4
+# 7 - 7
+# 20 - 6,8
+#
+adm12|lsi adm12,
+ am, mir,
+ cols#80, it#8, lines#24,
+ bel=^G, clear=^Z, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, ed=\EY, el=\ET, home=^^, hts=\E1, ich1=\EQ, il1=\EE,
+ is2=\E0 \E1 \E1 \E1 \E1 \E1 \E1 \E1 \E1,
+ kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, kf0=^A0\r, kf1=^A1\r,
+ kf2=^A2\r, kf3=^A3\r, kf4=^A4\r, kf5=^A5\r, kf6=^A6\r,
+ kf7=^A7\r, kf8=^A8\r, kf9=^A9\r, rmir=\Er, smir=\Eq, tbc=\E0,
+ use=adm+sgr,
+# (adm20: removed obsolete ":kn#7:" -- esr)
+adm20|lear siegler adm20,
+ am,
+ cols#80, it#8, lines#24,
+ bel=^G, cbt=\EI, clear=^Z, cr=^M, cub1=^H, cuf1=^L,
+ cup=\E=%i%p2%{31}%+%c%p1%{31}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, ed=\EY, el=\ET, home=^^, ht=^I, ich1=\EQ, il1=\EE,
+ kf1=^A, kf2=^B, kf3=^W, kf4=^D, kf5=^E, kf6=^X, kf7=^Z, rmso=\E(,
+ sgr0=\E(, smso=\E),
+adm21|lear siegler adm21,
+ xmc#1,
+ bel=^G, cr=^M, cud1=^J, dch1=\EW, dl1=30*\ER, ed=\EY, el=\ET,
+ ich1=\EQ, il1=30*\EE, ind=^J, invis@, kbs=^H, kcub1=^H,
+ kcud1=^J, kcuf1=^L, kcuu1=^K, khome=^^,
+ use=adm+sgr, use=adm3a,
+# (adm22: ":em=:" was an obvious typo for ":ei=:"; also,
+# removed obsolete ":kn#7:ma=j^Jk^P^K^Pl ^R^L^L :";
+# removed bogus-looking \200 from before <cup>. -- esr)
+adm22|lsi adm22,
+ am,
+ cols#80, lines#24,
+ bel=^G, cbt=\EI, clear=\E+, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, ed=\Ey, el=\Et, home=^^, ht=\Ei, ich1=\EQ, il1=\EE,
+ is2=\E%\014\014\014\016\003\0\003\002\003\002\0\0\0\0\0\0\0\0\0\0\0,
+ kbs=^H, kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, kf1=^A@\r,
+ kf2=^AA\r, kf3=^AB\r, kf4=^AC\r, kf5=^AD\r, kf6=^AE\r,
+ kf7=^AF\r, khome=^^, lf1=F1, lf2=F2, lf3=F3, lf4=F4, lf5=F5,
+ lf6=F6, lf7=F7, rmso=\E(, sgr0=\E(, smso=\E),
+# ADM 31 DIP Switches
+#
+# This information comes from two versions of the manual for the
+# Lear-Siegler ADM 31.
+#
+# Main board:
+# rear of case
+# +-||||-------------------------------------+
+# + S1S2 ||S +
+# + ||3 +
+# + +
+# + ||S +
+# + ||4 +
+# + +
+# + +
+# + +
+# + +
+# + +
+# +-+ +-+
+# + +
+# + S5 S6 S7 +
+# + == == == +
+# +----------------------------------------------+
+# front of case (keyboard)
+#
+# S1 - Data Rate - Modem
+# S2 - Data Rate - Printer
+# ------------------------
+# Data Rate Setting
+# -------------------
+# 50 0 0 0 0
+# 75 1 0 0 0
+# 110 0 1 0 0
+# 134.5 1 1 0 0
+# 150 0 0 1 0
+# 300 1 0 1 0
+# 600 0 1 1 0
+# 1200 1 1 1 0
+# 1800 0 0 0 1
+# 2000 1 0 0 1
+# 2400 0 1 0 1
+# 3600 1 1 0 1
+# 4800 0 0 1 1
+# 7200 1 0 1 1
+# 9600 0 1 1 1
+# x 1 1 1 1
+#
+# S3 - Interface/Printer/Attributes
+# ---------------------------------
+# Printer Busy Control
+# sw1 sw2 sw3
+# ---------------
+# off off off Busy not active, CD disabled
+# off off on Busy not active, CD enabled
+# off on off Busy active on J5-20, CD disabled
+# on off off Busy active on J5-19, CD disabled - Factory Set.
+# on off on Busy active on J5-19, CD enabled
+#
+# sw4 Used in conjuction with S4 for comm interface control - Fact 0
+#
+# sw5 Secondary Channel Control (Hardware implementation only) - Fact 0
+#
+# sw6 ON enables printer BUSY active LOW - Factory Setting
+# OFF enables printer BUSY active HIGH - If set to this, ADM31 senses
+#
+# sw7 ON - steady cursor - Factory Setting
+# OFF - blinking cursor
+#
+# sw8 ON causes selected attribute character to be displayed
+# OFF causes SPACE to be displayed instead - Factory Setting
+#
+# S4 - Interface
+# --------------
+# Modem Interface
+# S3 S4 S4 S4 S4
+# sw4 sw1 sw2 sw3 sw4
+# ---------------------------
+# OFF ON OFF ON OFF Enable RS-232C interface, Direct Connect and
+# Current Loop disabled - Factory Setting
+# ON ON OFF ON OFF Enable Current Loop interface, Direct Connect
+# disabled
+# OFF OFF ON OFF ON Enable Direct Connect interface, RS-232C and
+# Current Loop Disabled
+#
+# sw5 ON disables dot stretching mode - Factory Setting
+# OFF enables dot stretching mode
+# sw6 ON enables blanking function
+# OFF enables underline function - Factory Setting
+# sw7 ON causes NULLS to be displayed as NULLS
+# OFF causes NULLS to be displayed as SPACES - Factory Setting
+#
+# S5 - Word Structure
+# -------------------
+# sw1 ON enables BREAK key - Factory Setting
+# OFF disables BREAK key
+# sw2 ON selects 50Hz monitor refresh rate
+# OFF selects 60Hz monitor refresh rate - Factory Setting
+#
+# Modem Port Selection
+# sw3 sw4 sw5
+# ---------------
+# ON ON ON Selects 7 DATA bits, even parity, 2 STOP bits
+# OFF ON ON Selects 7 DATA bits, odd parity, 2 STOP bits
+# ON OFF ON Selects 7 DATA bits, even parity, 1 STOP bit - Factory Set.
+# OFF OFF ON Selects 7 DATA bits, odd parity, 1 STOP bit
+# ON ON OFF Selects 8 DATA bits, no parity, 2 STOP bits
+# OFF ON OFF Selects 8 DATA bits, no parity, 1 STOP bit
+# ON OFF OFF Selects 8 DATA bits, even parity, 1 STOP bit
+# OFF OFF OFF Selects 8 DATA bits, odd parity, 1 STOP bit
+#
+# sw6 ON sends bit 8 a 1 (mark)
+# OFF sends bit 8 as 0 (space) - Factory Setting
+# sw7 ON selects Block Mode
+# OFF selects Conversation Mode - Factory Setting
+# sw8 ON selects Full Duplex operation
+# OFF selects Half Duplex operation - Factory Setting
+#
+# S6 - Printer
+# ------------
+# sw1, sw2, sw6, sw7 Reserved - Factory 0
+#
+# Printer Port Selection
+# same as Modem above, bit 8 (when 8 DATA bits) is always = 0
+#
+# sw8 ON enables Printer Port
+# OFF disables Printer Port - Factory Setting
+#
+# S7 - Polling Address
+# --------------------
+# sw1-7 Establish ASCII character which designates terminal polling address
+# ON = logic 0
+# OFF = logic 1 - Factory Setting
+# sw8 ON enables Polling Option
+# OFF disables Polling Option - Factory Setting
+#
+#
+# On some older adm31s, S4 does not exist, and S5-sw6 is not defined.
+#
+# This adm31 entry uses underline as the standout mode.
+# If the adm31 gives you trouble with standout mode, check the DIP switch in
+# position 6, bank @c11, 25% from back end of the circuit board. Should be
+# OFF. If there is no such switch, you have an old adm31 and must use oadm31.
+# (adm31: removed obsolete ":ma=j^Jk^P^K^Pl ^R^L^L :" -- esr)
+adm31|lsi adm31 with sw6 set for underline mode,
+ am, mir,
+ cols#80, lines#24,
+ bel=^G, clear=\E*, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, ed=\EY, el=\ET, home=^^, il1=\EE, ind=^J, is2=\Eu\E0,
+ kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, kf0=^A0\r, kf1=^A1\r,
+ kf2=^A2\r, kf3=^A3\r, kf4=^A4\r, kf5=^A5\r, kf6=^A6\r,
+ kf7=^A7\r, kf8=^A8\r, kf9=^A9\r, rmir=\Er, rmso=\EG0,
+ rmul=\EG0, sgr0=\EG0, smir=\Eq, smso=\EG1, smul=\EG1,
+adm31-old|o31|old adm31,
+ rmul@, smso=\EG4, smul@, use=adm31,
+# LSI ADM-36 from Col. George L. Sicherman <gloria!colonel> via BRL
+adm36|LSI ADM36,
+ if=/usr/lib/tabset/vt100,
+ is2=\E<\E>\E[6;?2;?7;?8h\E[4;20;?1;?3;?4;?5;?6;?18;?19l, use=vt100,
+# (adm42: removed obsolete ":ma=^K^P:" -- esr)
+adm42|lsi adm42,
+ am,
+ cols#80, lines#24,
+ bel=^G, cbt=\EI, clear=\E;, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
+ cvvis=\EC\E3 \E3(, dch1=\EW, dl1=\ER, ed=\EY, el=\ET, ht=^I,
+ il1=\EE$<270>, ind=^J, invis@, ip=$<6*>, kcub1=^H, kcud1=^J,
+ kcuf1=^L, kcuu1=^K, khome=^^, pad=\177, rmir=\Er, rmul@,
+ smir=\Eq, smul@,
+ use=adm+sgr,
+# The following termcap for the Lear Siegler ADM-42 leaves the
+# "system line" at the bottom of the screen blank (for those who
+# find it distracting otherwise)
+adm42-ns|lsi adm-42 with no system line,
+ cbt=\EI\EF \011, clear=\E;\EF \011,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c$<6>\EF \011,
+ dch1=\EW\EF \011, dl1=\ER\EF \011, ed=\EY\EF \011,
+ el=\ET\EF \011, il1=\EE\EF \011, rmir=\Er\EF \011,
+ smir=\Eq\EF \011,
+ use=adm42,
+# ADM 1178 terminal -- rather like an ADM-42. Manual is dated March 1 1985.
+# The insert mode of this terminal is commented out because it's broken for our
+# purposes in that it will shift the position of every character on the page,
+# not just the cursor line!
+# From: Michael Driscoll <fenris@lightspeed.net> 10 July 1996
+adm1178|1178|lsi adm1178,
+ am,
+ cols#80, lines#24, xmc#1,
+ bel=^G, bold=\E(, cbt=\EI, clear=\E+, cr=^M, cub1=^H, cud1=^J,
+ cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
+ cvvis=\EC\E3 \E3(, dch1=\EW, dl1=\ER, ed=\EY, el=\ET,
+ home=^^, ht=^I, il1=\EE, ind=^J, ip=$<6*/>, kbs=^H, kcub1=^H,
+ kcud1=^J, nel=^M^J, pad=\177, rev=\EG4, rmso=\EG0, rmul=\EG0,
+ sgr0=\E), smso=\EG4, smul=\EG1,
+
+#### Prime
+#
+# Yes, Prime made terminals. These entries were posted by Kevin J. Cummings
+# <cummings@primerd.prime.com> on 14 Dec 1992 and lightly edited by esr.
+# Prime merged with ComputerVision in the late 1980s; you can reach them at:
+#
+# ComputerVision Services
+# 500 Old Connecticut Path
+# Framingham, Mass.
+#
+
+# Standout mode is dim reverse-video.
+pt100|pt200|wren|fenix|prime pt100/pt200,
+ am, bw, mir, msgr,
+ cols#80, it#8, lines#24,
+ cbt=\E[Z, clear=\E?, cr=^M, cub=\E[%p1%dD, cub1=^H,
+ cud=\E[%p1%dB, cud1=\ED, cuf=\E[%p1%dC, cuf1=\E[C,
+ cup=\E0%p1%{33}%+%c%p2%{33}%+%c, cuu=\E[%p1%dA,
+ cuu1=\EM, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m, dl=\E[M,
+ ed=\E[J\E[r, el=\E[K\E[t, flash=\E$$<200/>\E$P,
+ home=\E$B, ht=^I, il1=\E[L\E[t, ind=^J, kbs=^H, kcub1=\E[D,
+ kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A, khome=\E$A, nel=^M^J,
+ rmcup=, rmir=\E[4l, rmkx=\E[>13l, rmso=\E[m, rmul=\E[m,
+ sgr0=\E[m,
+ smcup=\E[>1l\E[>2l\E[>16l\E[4l\E[>9l\E[20l\E[>3l\E[>7h\E[>12l\E[1Q,
+ smir=\E[4h, smkx=\E[>13h, smso=\E[2;7m, smul=\E[4m,
+pt100w|pt200w|wrenw|fenixw|prime pt100/pt200 in 132-column mode,
+ cols#132,
+ cup=\E[%i%p1%d;%p2%dH, use=pt100,
+pt250|Prime PT250,
+ rmso@, smso@, use=pt100,
+pt250w|Prime PT250 in 132-column mode,
+ rmso@, smso@, use=pt100w,
+
+#### Qume (qvt)
+#
+# Qume, Inc.
+# 3475-A North 1st Street
+# San Jose CA 95134
+# Vox: (800)-457-4447
+# Fax: (408)-473-1510
+# Net: josed@techsupp.wyse.com (Jose D'Oliveira)
+#
+# Qume was bought by Wyse, but still (as of early 1995) has its own support
+# group and production division.
+#
+# Discontinued Qume models:
+#
+# The qvt101 and qvt102 listed here are long obsolete; so is the qvt101+
+# built to replace them, and a qvt119+ which was a 101+ with available wide
+# mode (132 columns). There was a qvt103 which added vt100/vt131 emulations
+# and an ANSI-compatible qvt203 that replaced it. Qume started producing
+# ANSI-compatible terminals with the qvt323 and qvt61.
+#
+# Current Qume models (as of February 1995):
+#
+# All current Qume terminals have ANSI-compatible operation modes.
+# Qume is still producing the qvt62, which features emulations for other
+# popular lines such as ADDS, and dual-host capabilities. The qvt82 is
+# designed for use as a SCO ANSI terminal. The qvt70 is a color terminal
+# with many emulations including Wyse370, Wyse 325, etc. Their newest
+# model is the qvt520, which is vt420-compatible.
+#
+# There are some ancient printing Qume terminals under `Daisy Wheel Printers'
+#
+# If you inherit a Qume without docs, try Ctrl-Shift-Setup to enter its
+# setup mode. Shift-s should be a configuration save to NVRAM.
+
+qvt101|qvt108|qume qvt 101 and QVT 108,
+ xmc#1, use=qvt101+,
+
+# This used to have <cvvis=\E.2> but no <cnorm> or <civis>. The BSD termcap
+# file had <cvvis=\EM4 \200\200\200>. I've done the safe thing and yanked
+# both. The <rev> is from BSD, which also claimed bold=\E( and dim=\E).
+# What seems to be going on here is that this entry was designed so that
+# the normal highlight is bold and standout is dim plus something else
+# (reverse-video maybe? But then, are there two <rev> sequences?)
+qvt101+|qvt101p|qume qvt 101 PLUS product,
+ am, bw, hs, ul,
+ cols#80, lines#24, xmc#0,
+ bel=^G, cbt=\EI, clear=^Z, cnorm=\E.4, cr=^M, cub1=^H, cud1=^J,
+ cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
+ dch1=\EW, dl1=\ER, dsl=\Eg\Ef\r, ed=\EY, el=\ET,
+ flash=\Eb$<200>\Ed, fsl=^M, home=^^, ht=^I, hts=\E1,
+ ich1=\EQ, il1=\EE, ind=^J, invis@, kbs=^H, kcbt=\EI, kcub1=^H,
+ kcud1=^J, kcuf1=^L, kcuu1=^K, kdl1=\ER, ked=\EY, kel=\ET,
+ kf1=^A@\r, kf10=^AI\r, kf2=^AA\r, kf3=^AB\r, kf4=^AC\r,
+ kf5=^AD\r, kf6=^AE\r, kf7=^AF\r, kf8=^AG\r, kf9=^AH\r,
+ khome=^^, kich1=\EQ, kil1=\EE, mc4=\EA, mc5=\E@, rmso=\E(,
+ smso=\E0P\E), tbc=\E3, tsl=\Eg\Ef,
+ use=adm+sgr,
+qvt102|qume qvt 102,
+ cnorm=\E., use=qvt101,
+# (qvt103: added <rmam>/<smam> based on init string -- esr)
+qvt103|qume qvt 103,
+ am, xenl, xon,
+ cols#80, it#8, lines#24, vt#3,
+ bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
+ clear=\E[H\E[2J$<50>, cr=^M, csr=\E[%i%p1%d;%p2%dr,
+ cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J,
+ 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>, home=\E[H, ht=^I,
+ hts=\EH, ind=^J, kbs=^H, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC,
+ kcuu1=\EOA, kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS, rc=\E8,
+ rev=\E[7m$<2>, ri=\EM$<5>, rmam=\E[?7l, rmkx=\E[?1l\E>,
+ rmso=\E[m$<2>, rmul=\E[m$<2>,
+ rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
+ sgr=\E[%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;m,
+ sgr0=\E[m$<2>, smam=\E[?7h, smkx=\E[?1h\E=,
+ smso=\E[7m$<2>, smul=\E[4m$<2>, tbc=\E[3g,
+qvt103-w|qume qvt103 132 cols,
+ cols#132, lines#24,
+ rs2=\E>\E[?3h\E[?4l\E[?5l\E[?8h, use=qvt103,
+qvt119+|qvt119p|qvt119|qume qvt 119 and 119PLUS terminals,
+ am, hs, mir, msgr,
+ cols#80, lines#24, xmc#0,
+ bel=^G, cbt=\EI, clear=\E*1, cnorm=\E.4, cr=^M, cub1=^H,
+ cud1=^J, cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c,
+ cuu1=^K, cvvis=\E.2, dch1=\EW, dl1=\ER, dsl=\Eg\Ef\r, ed=\Ey,
+ el=\Et, flash=\En0$<200>\En1, fsl=^M, home=^^, ht=^I,
+ hts=\E1, il1=\EE, ind=^J, is2=\EDF\EC\EG0\Er\E(\E%EX,
+ kbs=^H, kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, kf0=^AI\r,
+ kf1=^A@\r, kf2=^AA\r, kf3=^AB\r, kf4=^AC\r, kf5=^AD\r,
+ kf6=^AE\r, kf7=^AF\r, kf8=^AG\r, kf9=^AH\r, khome=^^,
+ mc4=\EA, mc5=\E@, ri=\EJ, rmir=\Er, smir=\Eq, smul=\EG8,
+ tbc=\E3, tsl=\Eg\Ef,
+ use=adm+sgr,
+qvt119+-25|qvt119p-25|QVT 119 PLUS with 25 data lines,
+ lines#25, use=qvt119+,
+qvt119+-w|qvt119p-w|qvt119-w|QVT 119 and 119 PLUS in 132 column mode,
+ cols#132,
+ is2=\EDF\EC\EG0\Er\E(\E%\EX\En4, use=qvt119+,
+qvt119+-25-w|qvt119p-25-w|qvt119-25-w|QVT 119 and 119 PLUS 132 by 25,
+ lines#25, use=qvt119+,
+qvt203|qvt203+|qume qvt 203 Plus,
+ dch1=\E[P$<7>, dl1=\E[M$<99>, il1=\E[L$<99>, ind=\n$<30>,
+ ip=$<7>, kf0=\E[29~, kf1=\E[17~, kf2=\E[18~, kf3=\E[19~,
+ kf4=\E[20~, kf5=\E[21~, kf6=\E[23~, kf7=\E[24~, kf8=\E[25~,
+ kf9=\E[28~, rmir=\E[4l, smir=\E[4h,
+ use=qvt103,
+qvt203-w|qvt203-w-am|qume qvt 203 PLUS in 132 cols (w/advanced video),
+ cols#132, lines#24,
+ rs2=\E>\E[?3h\E[?4l\E[?5l\E[?8h, use=qvt203,
+#
+# Since a command is present for enabling 25 data lines,
+# a specific terminfo entry may be generated for the 203.
+# If one is desired for the QVT 119 PLUS then 25 lines must
+# be selected in the status line (setup line 9).
+#
+qvt203-25|QVT 203 PLUS with 25 by 80 column mode,
+ cols#80, lines#25,
+ is2=\E[=40h\E[?3l, use=qvt203,
+qvt203-25-w|QVT 203 PLUS with 25 by 132 columns,
+ cols#132, lines#25,
+ rs2=\E[?3h\E[=40h, use=qvt203,
+
+#### Televideo (tvi)
+#
+# TeleVideo
+# 550 East Brokaw Road
+# PO Box 49048 95161
+# San Jose CA 95112
+# Vox: (408)-954-8333
+# Fax: (408)-954-0623
+#
+#
+# There are some tvi terminals that require incredible amounts of padding and
+# some that don't. I'm assuming tvi912 and tvi920 are the old slow ones, and
+# tvi912b, tvi912c, tvi920b, tvi920c are the new ones that don't need padding.
+#
+# All of these terminals (912 to 970 and the tvipt) are discontinued. Newer
+# Televideo terminals are ANSI and PC-ANSI compatible.
+
+tvi803|televideo 803,
+ clear=\E*$<10>, use=tvi950,
+
+# Vanilla tvi910 -- W. Gish <cswarren@violet> 10/29/86
+# Switch settings are:
+#
+# S1 1 2 3 4
+# D D D D 9600
+# D D D U 50
+# D D U D 75
+# D D U U 110
+# D U D D 135
+# D U D U 150
+# D U U D 300
+# D U U U 600
+# U D D D 1200
+# U D D U 1800
+# U D U D 2400
+# U D U U 3600
+# U U D D 4800
+# U U D U 7200
+# U U U D 9600
+# U U U U 19200
+#
+# S1 5 6 7 8
+# U D X D 7N1 (data bits, parity, stop bits) (X means ignored)
+# U D X U 7N2
+# U U D D 7O1
+# U U D U 7O2
+# U U U D 7E1
+# U U U U 7E2
+# D D X D 8N1
+# D D X U 8N2
+# D U D D 8O1
+# D U U U 8E2
+#
+# S1 9 Autowrap
+# U on
+# D off
+#
+# S1 10 CR/LF
+# U do CR/LF when CR received
+# D do CR when CR received
+#
+# S2 1 Mode
+# U block
+# D conversational
+#
+# S2 2 Duplex
+# U half
+# D full
+#
+# S2 3 Hertz
+# U 50
+# D 60
+#
+# S2 4 Edit mode
+# U local
+# D duplex
+#
+# S2 5 Cursor type
+# U underline
+# D block
+#
+# S2 6 Cursor down key
+# U send ^J
+# D send ^V
+#
+# S2 7 Screen colour
+# U green on black
+# D black on green
+#
+# S2 8 DSR status (pin 6)
+# U disconnected
+# D connected
+#
+# S2 9 DCD status (pin 8)
+# U disconnected
+# D duplex
+#
+# S2 10 DTR status (pin 20)
+# U disconnected
+# D duplex
+# (tvi910: removed obsolete ":ma=^Kk^Ll^R^L:"; added <khome>, <cub1>, <cud1>,
+# <ind>, <hpa>, <vpa>, <am>, <msgr> from SCO entry -- esr)
+tvi910|televideo model 910,
+ am, msgr,
+ cols#80, it#8, lines#24, xmc#1,
+ bel=^G, cbt=\EI, clear=^Z, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, ed=\EY, el=\ET,
+ home=\E=\001\001, hpa=\E]%p1%{32}%+%c, ht=^I,
+ if=/usr/share/tabset/stdcrt, ind=^J, invis@, kbs=^H,
+ kcub1=^H, kcud1=^J, kcuf1=^L, kcuu1=^K, kf0=^AI\r, kf1=^A@\r,
+ kf2=^AA\r, kf3=^AB\r, kf4=^AC\r, kf5=^AD\r, kf6=^AE\r,
+ kf7=^AF\r, kf8=^AG\r, kf9=^AH\r, khome=^^,
+ vpa=\E[%p1%{32}%+%c, use=adm+sgr,
+# From: Alan R. Rogers <rogers%albany@csnet-relay>
+# as subsequently hacked over by someone at SCO
+# (tvi910+: removed obsolete ":ma=^K^P^L :" -- esr)
+#
+# Here are the 910+'s DIP switches (U = up, D = down, X = don't care):
+#
+# S1 1 2 3 4:
+# D D D D 9600 D D D U 50 D D U D 75 D D U U 110
+# D U D D 135 D U D U 150 D U U D 300 D U U U 600
+# U D D D 1200 U D D U 1800 U D U D 2400 U D U U 3600
+# U U D D 4800 U U D U 7200 U U U D 9600 U U U U 19200
+#
+# S1 5 6 7 8:
+# U D X D 7N1 U D X U 7N2 U U D D 7O1 U U D U 7O2
+# U U U D 7E1 U U U U 7E2 D D X D 8N1 D D X U 8N2
+# D U D D 8O1 D U U U 8E2
+#
+# S1 9 Autowrap (U = on, D = off)
+# S1 10 CR/LF (U = CR/LF on CR received, D = CR on CR received)
+# S2 1 Mode (U = block, D = conversational)
+# S2 2 Duplex (U = half, D = full)
+# S2 3 Hertz (U = 50, D = 60)
+# S2 4 Edit mode (U = local, D = duplex)
+# S2 5 Cursor type (U = underline, D = block)
+# S2 6 Cursor down key (U = send ^J, D = send ^V)
+# S2 7 Screen colour (U = green on black, D = black on green)
+# S2 8 DSR status (pin 6) (U = disconnected, D = connected)
+# S2 9 DCD status (pin 8) (U = disconnected, D = connected)
+# S2 10 DTR status (pin 20) (U = disconnected, D = connected)
+#
+tvi910+|televideo 910+,
+ dch1=\EW, dl1=\ER$<33*>, home=^^, ich1=\EQ, il1=\EE$<33*>,
+ kf0=^A@\r, kf1=^AA\r, kf2=^AB\r, kf3=^AC\r, kf4=^AD\r,
+ kf5=^AE\r, kf6=^AF\r, kf7=^AG\r, kf8=^AH\r, kf9=^AI\r,
+ ll=\E=7\s,
+ use=tvi910,
+
+# (tvi912: removed obsolete ":ma=^K^P^L :", added <flash> and
+# <khome> from BRL entry -- esr)
+tvi912|tvi914|tvi920|old televideo 912/914/920,
+ am, msgr,
+ cols#80, it#8, lines#24, xmc#1,
+ bel=^G, clear=^Z, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER$<33*>, ed=\Ey, el=\ET, flash=\Eb$<50/>\Ed, home=^^,
+ ht=^I, hts=\E1, ich1=\EQ, if=/usr/share/tabset/stdcrt,
+ il1=\EE$<33*>, ind=^J, kbs=^H, kcub1=^H, kcud1=^J, kcuf1=^L,
+ kcuu1=^K, kf0=^AI\r, kf1=^A@\r, kf2=^AA\r, kf3=^AB\r,
+ kf4=^AC\r, kf5=^AD\r, kf6=^AE\r, kf7=^AF\r, kf8=^AG\r,
+ kf9=^AH\r, khome=^^, rmso=\Ek, rmul=\Em, smso=\Ej, smul=\El,
+ tbc=\E3,
+# the 912 has a <funct> key that's like shift: <funct>8 xmits "^A8\r".
+# The 920 has this plus real function keys that xmit different things.
+# Terminfo makes you use the funct key on the 912 but the real keys on the 920.
+tvi912c|tvi912b|new televideo 912,
+ dl1=\ER$<5*>, il1=\EE$<5*>, use=tvi912,
+# set to page 1 when entering curses application (\E-17 )
+# reset to page 0 when exiting curses application (\E-07 )
+tvi912-2p|tvi920-2p|tvi-2p|televideo w/2 pages,
+ rmcup=\E-07\s, smcup=\E-17\s, use=tvi912,
+# We got some new tvi912c terminals that act really weird on the regular
+# termcap, so one of our gurus worked this up. Seems that cursor
+# addressing is broken.
+tvi912cc|tvi912 at cowell college,
+ cup@, use=tvi912c,
+
+# Here are the switch settings for the tvi920c:
+#
+# S1 (Line), and S3 (Printer) baud rates -- put one, and only one, switch down:
+# 2: 9600 3: 4800 4: 2400 5: 1200
+# 6: 600 7: 300 8: 150 9: 75
+# 10: 110
+#
+# S2 UART/Terminal options:
+# Up Down
+# 1: Not used Not allowed
+# 2: Alternate character set Standard character set
+# 3: Full duplex Half duplex
+# 4: 50 Hz refresh 60 Hz refresh
+# 5: No parity Send parity
+# 6: 2 stop bits 1 stop bit
+# 7: 8 data bits 7 data bits
+# 8: Not used Not allowed on Rev E or lower
+# 9: Even parity Odd parity
+# 10: Steady cursor Blinking cursor
+# (On Rev E or lower, use W25 instead of switch 10.)
+#
+# S5 UART/Terminal options:
+# Open Closed
+# 1: P3-6 Not connected DSR received on P3-6
+# 2: P3-8 Not connected DCD received on P3-8
+#
+# 3 Open, 4 Open: P3-20 Not connected
+# 3 Open, 4 Closed: DTR on when terminal is on
+# 3 Closed, 4 Open: DTR is connected to RTS
+# 3 Closed, 4 Closed: Not allowed
+#
+# 5 Closed: HDX printer (hardware control) Rev. K with extension port off,
+# all data transmitted out of the modem port (P3) will also be
+# transmitted out of the printer port (P4).
+#
+# 6 Open, 7 Open: Not allowed
+# 6 Open, 7 Closed: 20ma current loop input
+# 6 Closed, 7 Open: RS232 input
+# 6 Closed, 7 Closed: Not allowed
+#
+# Jumper options:
+# If the jumper is installed, the effect will occur (the next time the terminal
+# is switched on).
+#
+# S4/W31: Enables automatic LF upon receipt of CR from
+# remote or keyboard.
+# S4/W32: Enables transmission of EOT at the end of Send. If not
+# installed, a carriage return is sent.
+# S4/W33: Disables automatic carriage return in column 80.
+# S4/W34: Selects Page Print Mode as initial condition. If not
+# installed, Extension Mode is selected.
+#
+tvi920b|tvi920c|new televideo 920,
+ dl1=\ER$<5*>, il1=\EE$<5*>, kf0=^AI\r, kf1=^A@\r,
+ kf2=^AA\r, kf3=^AB\r, kf4=^AC\r, kf5=^AD\r, kf6=^AE\r,
+ kf7=^AF\r, kf8=^AG\r, kf9=^AH\r,
+ use=tvi912,
+
+# Televideo 921 and variants
+# From: Tim Theisen <tim@cs.wisc.edu> 22 Sept 1995
+# (tvi921: removed :ko=bt: before translation, I see no backtab cap;
+# also added empty <acsc> to suppress tic warning -- esr)
+tvi921|televideo model 921 with sysline same as page & real vi function,
+ am, hs, xenl, xhp,
+ cols#80, lines#24, xmc#0,
+ acsc=, clear=^Z, cnorm=\E.3, cr=^M, cub1=^H, cud1=^V, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c$<3/>, cuu1=^K,
+ cvvis=\E.2, dch1=\EW, dl1=\ER$<1*/>, dsl=\Ef\r\Eg, ed=\EY,
+ el=\ET, fsl=\Eg, home=^^, ht=^I, ich1=\EQ,
+ if=/usr/share/tabset/stdcrt, il1=\EE, ind=^J, invis@,
+ is2=\El\E"\EF1\E.3\017\EA\E<, kbs=^H, kclr=^Z, kcub1=^H,
+ kcud1=^V, kcuf1=^L, kcuu1=^K, kdch1=\EW, kdl1=\ER$<1*/>,
+ ked=\EY, kel=\ET, kich1=\EQ, kil1=\EE, nel=^M^J, rmacs=\E%,
+ rmir=, smacs=\E$, smir=, tsl=\Ef\EG0,
+ use=adm+sgr,
+# without the beeper
+# (tvi92B: removed :ko=bt: before translation, I see no backtab cap;
+# also added empty <acsc> to suppress tic warning -- esr)
+tvi92B|televideo model 921 with sysline same as page & real vi function & no beeper,
+ am, hs, xenl, xhp,
+ cols#80, lines#24, xmc#0,
+ acsc=, clear=^Z, cnorm=\E.3, cr=^M, cub1=^H, cud1=^V, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c$<3/>, cuu1=^K,
+ cvvis=\E.2, dch1=\EW, dl1=\ER$<1*/>, dsl=\Ef\r\Eg, ed=\EY,
+ el=\ET, flash=\Eb$<200/>\Ed, fsl=\Eg, home=^^, ht=^I,
+ ich1=\EQ, if=/usr/share/tabset/stdcrt, il1=\EE, ind=^J,
+ invis@, is2=\El\E"\EF1\E.3\017\EA\E<, kbs=^H, kclr=^Z,
+ kcub1=^H, kcud1=^V, kcuf1=^L, kcuu1=^K, kdch1=\EW,
+ kdl1=\ER$<1*/>, ked=\EY, kel=\ET, kich1=\EQ, kil1=\EE,
+ nel=^M^J, rmacs=\E%, smacs=\E$, tsl=\Ef\EG0,
+ use=adm+sgr,
+# (tvi92D: removed :ko=bt: before translation, I see no backtab cap -- esr)
+tvi92D|tvi92B with DTR instead of XON/XOFF & better padding,
+ dl1=\ER$<2*/>, il1=\EE$<2*/>,
+ is2=\El\E"\EF1\E.3\016\EA\E<, kdl1=\ER$<2*/>,
+ kil1=\EE$<2*/>,
+ use=tvi92B,
+
+# (tvi924: This used to have <dsl=\Es0>, <fsl=\031>. I put the new strings
+# in from a BSD termcap file because it looks like they do something the
+# old ones skip -- esr)
+tvi924|televideo tvi924,
+ am, bw, hs, in, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#24, wsl#80, xmc#0,
+ bel=^G, blink=\EG2, cbt=\EI, civis=\E.0, clear=\E*0,
+ cnorm=\E.3, cr=^M, csr=\E_%p1%{32}%+%c%p2%{32}%+%c,
+ cub1=^H, cud1=^V, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, cvvis=\E.1,
+ dch1=\EW, dl1=\ER, dsl=\Es0\Ef\031, ed=\Ey, el=\Et,
+ flash=\Eb$<200>\Ed, fsl=\031\Es1, home=^^, ht=^I, hts=\E1,
+ ich1=\EQ, if=/usr/share/tabset/stdcrt, il1=\EE, ind=^J,
+ invis@, is1=\017\E%\E'\E(\EDF\EC\EG0\EN0\Es0\Ev0,
+ kbs=^H, kclr=\E*0, kcub1=^H, kcud1=^V, kcuf1=^L, kcuu1=^K,
+ kdch1=\EW, kdl1=\ER, ked=\Ey, kel=\Et, kf0=^A@\r, kf1=^AA\r,
+ kf10=^AJ\r, kf11=^AK\r, kf12=^AL\r, kf13=^AM\r, kf14=^AN\r,
+ kf15=^AO\r, kf2=^AB\r, kf3=^AC\r, kf4=^AD\r, kf5=^AE\r,
+ kf6=^AF\r, kf7=^AG\r, kf8=^AH\r, kf9=^AI\r, khome=^^,
+ kich1=\EQ, kil1=\EE, lf0=F1, lf1=F2, lf10=F11, lf2=F3, lf3=F4,
+ lf4=F5, lf5=F6, lf6=F7, lf7=F8, lf8=F9, lf9=F10,
+ pfkey=\E|%p1%{49}%+%c%p2%s\031, ri=\Ej, tbc=\E3, tsl=\Ef, use=adm+sgr,
+
+# TVI925 DIP switches. In each of these, D = Down and U = Up,
+#
+# Here are the settings for the external (baud) switches (S1):
+#
+# Position Baud
+# 7 8 9 10 [Printer]
+# 1 2 3 4 [Main RS232]
+# -----------------------------------------------------
+# D D D D 9600
+# D D D U 50
+# D D U D 75
+# D D U U 110
+# D U D D 135
+# D U D U 150
+# D U U D 300
+# D U U U 600
+# U D D D 1200
+# U D D U 1800
+# U D U D 2400
+# U D U U 3600
+# U U D D 4800
+# U U D U 7200
+# U U U D 9600
+# U U U U 19200
+#
+#
+# Settings for word length and stop-bits (S1)
+#
+# Position Description
+# 5 6
+# ---------------------------
+# U - 7-bit word
+# D - 8-bit word
+# - U 2 stop bits
+# - D 1 stop bit
+#
+#
+# S2 (external) settings
+#
+# Position Up Dn Description
+# --------------------------------------------
+# 1 X Local edit
+# X Duplex edit (transmit editing keys)
+# --------------------------------------------
+# 2 X 912/920 emulation
+# X 925
+# --------------------------------------------
+# 3 X
+# 4 X No parity
+# 5 X
+# --------------------------------------------
+# 3 X
+# 4 X Odd parity
+# 5 X
+# --------------------------------------------
+# 3 X
+# 4 X Even parity
+# 5 X
+# --------------------------------------------
+# 3 X
+# 4 X Mark parity
+# 5 X
+# --------------------------------------------
+# 3 X
+# 4 X Space parity
+# 5 X
+# --------------------------------------------
+# 6 X White on black display
+# X Black on white display
+# --------------------------------------------
+# 7 X Half Duplex
+# 8 X
+# --------------------------------------------
+# 7 X Full Duplex
+# 8 X
+# --------------------------------------------
+# 7 X Block mode
+# 8 X
+# --------------------------------------------
+# 9 X 50 Hz
+# X 60 Hz
+# --------------------------------------------
+# 10 X CR/LF (Auto LF)
+# X CR only
+#
+# S3 (internal switch) settings:
+#
+# Position Up Dn Description
+# --------------------------------------------
+# 1 X Keyclick off
+# X Keyclick on
+# --------------------------------------------
+# 2 X English
+# 3 X
+# --------------------------------------------
+# 2 X German
+# 3 X
+# --------------------------------------------
+# 2 X French
+# 3 X
+# --------------------------------------------
+# 2 X Spanish
+# 3 X
+# --------------------------------------------
+# 4 X Blinking block cursor
+# 5 X
+# --------------------------------------------
+# 4 X Blinking underline cursor
+# 5 X
+# --------------------------------------------
+# 4 X Steady block cursor
+# 5 X
+# --------------------------------------------
+# 4 X Steady underline cursor
+# 5 X
+# --------------------------------------------
+# 6 X Screen blanking timer (ON)
+# X Screen blanking timer (OFF)
+# --------------------------------------------
+# 7 X Page attributes
+# X Line attributes
+# --------------------------------------------
+# 8 X DCD disconnected
+# X DCD connected
+# --------------------------------------------
+# 9 X DSR disconnected
+# X DSR connected
+# --------------------------------------------
+# 10 X DTR Disconnected
+# X DTR connected
+# --------------------------------------------
+#
+# (tvi925: BSD has <clear=\E*>. I got <is2> and <ri> from there -- esr)
+tvi925|televideo 925,
+ am, bw, hs, ul,
+ cols#80, lines#24, xmc#1,
+ bel=^G, cbt=\EI, clear=^Z, cnorm=\E.4, cr=^M, cub1=^H, cud1=^V,
+ cuf1=^L, cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K,
+ cvvis=\E.2, dch1=\EW, dl1=\ER, dsl=\Eh, ed=\EY, el=\ET,
+ flash=\Eb$<200>\Ed, fsl=^M\Eg, home=^^, ht=^I, hts=\E1,
+ ich1=\EQ, il1=\EE, ind=^J, invis@, is2=\El\E", kbs=^H, kclr=^Z,
+ kcub1=^H, kcud1=^V, kcuf1=^L, kcuu1=^K, kdch1=\EW, kdl1=\ER,
+ ked=\EY, kel=\ET, kf0=^AI\r, kf1=^A@\r, kf2=^AA\r, kf3=^AB\r,
+ kf4=^AC\r, kf5=^AD\r, kf6=^AE\r, kf7=^AF\r, kf8=^AG\r,
+ kf9=^AH\r, khome=^^, kich1=\EQ, kil1=\EE, ri=\Ej, tbc=\E3,
+ tsl=\Eh\Ef,
+ use=adm+sgr,
+# TeleVideo 925 from Mitch Bradley <sun!wmb> via BRL
+# to avoid "magic cookie" standout glitch:
+tvi925-hi|TeleVideo Model 925 with half intensity standout mode,
+ xmc@,
+ kbs=^H, kcub1=^H, kcud1=^J, rmso=\E(, smso=\E), use=tvi925,
+
+# From: Todd Litwin <litwin@litwin.jpl.nasa.gov> 28 May 1993
+# Originally Tim Curry, Univ. of Central Fla., <duke!ucf-cs!tim> 5/21/82
+# for additional capabilities,
+# The following tvi descriptions from B:pjphar and virus!mike
+# is for all 950s. It sets the following attributes:
+# full duplex (\EDF) write protect off (\E()
+# conversation mode (\EC) graphics mode off (\E%)
+# white on black (\Ed) auto page flip off (\Ew)
+# turn off status line (\Eg) clear status line (\Ef\r)
+# normal video (\E0) monitor mode off (\EX or \Eu)
+# edit mode (\Er) load blank char to space (\Ee\040)
+# line edit mode (\EO) enable buffer control (^O)
+# protect mode off (\E\047) duplex edit keys (\El)
+# program unshifted send key to send line all (\E016)
+# program shifted send key to send line unprotected (\E004)
+# set the following to nulls:
+# field delimiter (\Ex0\200\200)
+# line delimiter (\Ex1\200\200)
+# start-protected field delimiter (\Ex2\200\200)
+# end-protected field delimiter (\Ex3\200\200)
+# set end of text delimiter to carriage return/null (\Ex4\r\200)
+#
+# TVI 950 Switch Setting Reference Charts
+#
+# TABLE 1:
+#
+# S1 1 2 3 4 5 6 7 8 9 10
+# +-----------------------+-----+-----+-----------------------+
+# | Computer Baud Rate |Data |Stop | Printer Baud Rate |
+# | |Bits |Bits | |
+# +------+-----------------------+-----+-----+-----------------------+
+# | Up | See | 7 | 2 | See |
+# +------+-----------------------+-----+-----+-----------------------+
+# | Down | TABLE 2 | 8 | 1 | TABLE 2 |
+# +------+-----------------------+-----+-----+-----------------------+
+#
+#
+# S2 1 2 3 4 5 6 7 8 9 10
+# +-----+-----+-----------------+-----+-----------+-----+-----+
+# |Edit |Cursr| Parity |Video|Transmiss'n| Hz |Click|
+# +------+-----+-----+-----------------+-----+-----------+-----+-----+
+# | Up | Dplx|Blink| See |GonBk| See | 60 | Off |
+# +------+-----+-----+-----------------+-----+-----------+-----+-----+
+# | Down |Local|St'dy| TABLE 3 |BkonG| CHART | 50 | On |
+# +------+-----+-----+-----------------+-----+-----------+-----+-----+
+#
+# TABLE 2:
+#
+# +-----------+-----+-----+-----+-----+-----------+
+# | Display | 1 | 2 | 3 | 4 | Baud |
+# +-----------+-----+-----+-----+-----+ |
+# | Printer | 7 | 8 | 9 | 10 | Rate |
+# +-----------+-----+-----+-----+-----+-----------+
+# | D | D | D | D | 9600 |
+# | U | D | D | D | 50 |
+# | D | U | D | D | 75 |
+# | U | U | D | D | 110 |
+# | D | D | U | D | 135 |
+# | U | D | U | D | 150 |
+# | D | U | U | D | 300 |
+# | U | U | U | D | 600 |
+# | D | D | D | U | 1200 |
+# | U | D | D | U | 1800 |
+# | D | U | D | U | 2400 |
+# | U | U | D | U | 3600 |
+# | D | D | U | U | 4800 |
+# | U | D | U | U | 7200 |
+# | D | U | U | U | 9600 |
+# | U | U | U | U | 19200 |
+# +-----+-----+-----+-----+-----------+
+#
+# TABLE 3:
+# +-----+-----+-----+-----------+
+# | 3 | 4 | 5 | Parity |
+# +-----+-----+-----+-----------+
+# | X | X | D | None |
+# | D | D | U | Odd |
+# | D | U | U | Even |
+# | U | D | U | Mark |
+# | U | U | U | Space |
+# +-----+-----+-----+-----------+
+# X = don't care
+#
+# CHART:
+# +-----+-----+-----------------+
+# | 7 | 8 | Communication |
+# +-----+-----+-----------------+
+# | D | D | Half Duplex |
+# | D | U | Full Duplex |
+# | U | D | Block |
+# | U | U | Local |
+# +-----+-----+-----------------+
+#
+# (tvi950: early versions had obsolete ":ma=^Vj^Kk^Hh^Ll^^H:".
+# I also inserted <ich1> and <kich1>; the :ko: string indicated that <ich>
+# should be present and all tvi native modes use the same string for this.
+# Finally, note that BSD has cud1=^V. -- esr)
+tvi950|televideo 950,
+ am, hs, mir, msgr, xenl, xon,
+ cols#80, it#8, lines#24, xmc#1,
+ acsc=b\011c\014d\re\ni\013, bel=^G, cbt=\EI, clear=\E*,
+ cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dch1=\EW,
+ dl1=\ER, dsl=\Eg\Ef\r, ed=\Ey, el=\Et, flash=\Eb$<200/>\Ed,
+ fsl=^M, home=^^, ht=^I, hts=\E1, ich1=\EQ, il1=\EE, ind=^J,
+ invis@,
+ is2=\EDF\EC\Ed\EG0\Eg\Er\EO\E'\E(\E%\Ew\EX\Ee \017\011\El\E016\E004\Ex0\0\0\Ex1\0\0\Ex2\0\0\011\Ex3\0\0\Ex4\r\0\Ef\r,
+ kbs=^H, kcbt=\EI, kclr=\E*, kcub1=^H, kcud1=^V, kcuf1=^L,
+ kcuu1=^K, kdch1=\EW, kdl1=\ER, ked=\Ey, kel=\Et, kf0=^A0\r,
+ kf1=^A@\r, kf2=^AA\r, kf3=^AB\r, kf4=^AC\r, kf5=^AD\r,
+ kf6=^AE\r, kf7=^AF\r, kf8=^AG\r, kf9=^AH\r, khome=^^,
+ kich1=\EQ, kil1=\EE, mc4=\Ea, mc5=\E`, ri=\Ej, rmacs=^X,
+ rmir=\Er, smacs=^U, smir=\Eq, tbc=\E3, tsl=\Eg\Ef,
+ use=adm+sgr,
+#
+# is for 950 with two pages adds the following:
+# set 48 line page (\E\\2)
+# place cursor at page 0, line 24, column 1 (\E-07 )
+# set local (no send) edit keys (\Ek)
+#
+# two page 950 adds the following:
+# when entering ex, set 24 line page (\E\\1)
+# when exiting ex, reset 48 line page (\E\\2)
+# place cursor at 0,24,1 (\E-07 )
+# set duplex (send) edit keys (\El) when entering vi
+# set local (no send) edit keys (\Ek) when exiting vi
+#
+tvi950-2p|televideo950 w/2 pages,
+ is2=\EDF\EC\Ed\EG0\Eg\Er\EO\E'\E(\E%\Ew\EX\Ee \017\011\Ek\E016\E004\Ex0\0\0\Ex1\0\0\Ex2\0\0\011\Ex3\0\0\Ex4\r\0\E\\2\E-07 \011,
+ rmcup=\E\\2\E-07\s, rmkx=\Ek, smcup=\E\\1\E-07\s,
+ smkx=\El,
+ use=tvi950,
+#
+# is for 950 with four pages adds the following:
+# set 96 line page (\E\\3)
+# place cursor at page 0, line 24, column 1 (\E-07 )
+#
+# four page 950 adds the following:
+# when entering ex, set 24 line page (\E\\1)
+# when exiting ex, reset 96 line page (\E\\3)
+# place cursor at 0,24,1 (\E-07 )
+#
+tvi950-4p|televideo950 w/4 pages,
+ is2=\EDF\EC\Ed\EG0\Eg\Er\EO\E'\E(\E%\Ew\EX\Ee \017\011\Ek\E016\E004\Ex0\0\0\Ex1\0\0\Ex2\0\0\011\Ex3\0\0\Ex4\r\0\E\\3\E-07 \011,
+ rmcup=\E\\3\E-07\s, rmkx=\Ek, smcup=\E\\1\E-07\s,
+ smkx=\El,
+ use=tvi950,
+#
+# <is2> for reverse video 950 changes the following:
+# set reverse video (\Ed)
+#
+# set vb accordingly (\Ed ...delay... \Eb)
+#
+tvi950-rv|televideo950 rev video,
+ flash=\Ed$<200/>\Eb,
+ is2=\EDF\EC\Eb\EG0\Eg\Er\EO\E'\E(\E%\Ew\EX\Ee \017\011\El\E016\E004\Ex0\0\0\Ex1\0\0\Ex2\0\0\011\Ex3\0\0\Ex4\r\0, use=tvi950,
+
+# tvi950-rv-2p uses the appropriate entries from 950-2p and 950-rv
+tvi950-rv-2p|televideo950 rev video w/2 pages,
+ flash=\Ed$<200/>\Eb,
+ is2=\EDF\EC\Eb\EG0\Eg\Er\EO\E'\E(\E%\Ew\EX\Ee \017\011\Ek\E016\E004\Ex0\0\0\Ex1\0\0\Ex2\0\0\011\Ex3\0\0\Ex4\r\0\E\\2\E-07\s,
+ rmcup=\E\\2\E-07\s, rmkx=\Ek, smcup=\E\\1\E-07\s,
+ smkx=\El,
+ use=tvi950,
+
+# tvi950-rv uses the appropriate entries from 950-4p and 950-rv
+tvi950-rv-4p|televideo950 rev video w/4 pages,
+ flash=\Ed$<200/>\Eb,
+ is2=\EDF\EC\Eb\EG0\Er\EO\E'\E(\E%\Ew\EX\Ee \017\011\Ek\E016\E004\Ex0\0\0\Ex1\0\0\Ex2\0\0\011\Ex3\0\0\Ex4\r\0\E\\3\E-07\s,
+ rmcup=\E\\3\E-07\s, rmkx=\Ek, smcup=\E\\1\E-07\s,
+ smkx=\El,
+ use=tvi950,
+# From: Andreas Stolcke <stolcke@icsi.berkeley.edu>
+# (tvi955: removed obsolete ":ma:=^Vj^Kk^Hh^Ll^^H";
+# removed incorrect (and overridden) ":do=^J:"; fixed broken continuations in
+# the :rs: string, inserted the <ich> implied by the termcap :ko: string. Note
+# the :ko: string had :cl: in it, which means that one of the original
+# <clear=\E*>, <kclr=\EY> had to be wrong; set <kclr=\E*> because that's what
+# the 950 has. Finally, corrected the <kel> string to match the 950 and what
+# ko implies -- esr)
+# If the BSD termcap file was right, <cup=\E=%p1%{32}%+%c%p2%{32}%+%c> would
+# also work.
+tvi955|televideo 955,
+ mc5i, msgr@,
+ it#8, xmc@,
+ acsc=0_`RjHkGlFmEnIoPqKsQtMuLvOwNxJ, blink=\EG2,
+ civis=\E.0, cnorm=\E.2, cud1=^V, cup=\E[%i%p1%d;%p2%dH,
+ cvvis=\E.1, dim=\E[=5h, ind@, invis=\EG1,
+ is2=\E[=3l\EF1\Ed\EG0\E[=5l\E%\El, kctab=\E2, khts=\E1,
+ knp=\EK, kpp=\EJ, krmir=\EQ, ktbc=\E3, mc0=\EP, rmacs=\E%,
+ rmam=\E[=7l, rmxon=^N,
+ rs1=\EDF\EC\Eg\Er\EO\E'\E(\Ew\EX\Ee \017\E0P\E6\0\E0p\E4\0\Ef\r,
+ sgr0=\EG0\E[=5l, smacs=\E$, smam=\E[=7h, smxon=^O,
+ use=tvi950,
+tvi955-w|955-w|televideo955 w/132 cols,
+ cols#132,
+ is2=\E[=3h\EF1\Ed\EG0\E[=5l\E%\El, use=tvi955,
+# use half-intensity as normal mode, full intensity as <bold>
+tvi955-hb|955-hb|televideo955 half-bright,
+ bold=\E[=5l, dim@, is2=\E[=3l\EF1\Ed\EG0\E[=5h\E%\El,
+ sgr0=\EG0\E[=5h,
+ use=tvi955,
+# From: Humberto Appleton <beto@cs.utexas.edu>, 880521 UT Austin
+# (tvi970: removed ":sg#0:"; removed <rmso>=\E[m, <rmul>=\E[m;
+# added <am>/<csr>/<home>/<hpa>/<vpa>/<smcup>/<rmcup> from BRL.
+# According to BRL we could have <rmkx>=\E>, <smkx>=\E= but I'm not sure what
+# it does to the function keys. I deduced <rmam>/<smam>.
+# also added empty <acsc> to suppress tic warning, -- esr)
+tvi970|televideo 970,
+ am, da, db, mir, msgr,
+ cols#80, it#8, lines#24,
+ acsc=, cbt=\E[Z, clear=\E[H\E[2J, csr=\E[%i%p1%d;%p2%dr,
+ cub1=^H, cud1=\ED, cuf1=\E[C, cup=\E[%i%p1%d;%p2%df,
+ cuu1=\EM, cvvis=\E[1Q, dch1=\E[P, dl1=\E[M, dsl=\Eg\Ef\r,
+ ed=\E[J, el=\E[K, flash=\E[5m$<200/>\E[m, home=\E[H,
+ hpa=\E[%i%p1%dG, ht=^I, il1=\E[L,
+ is2=\E<\E[?21l\E[19h\E[1Q\E[10l\E[7l\E[H\E[2J,
+ kbs=^H, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kf1=\E?a, kf2=\E?b, kf3=\E?c, kf4=\E?d, kf5=\E?e, kf6=\E?f,
+ kf7=\E?g, kf8=\E?h, kf9=\E?i, khome=\E[H, ri=\EM, rmacs=\E(B,
+ rmam=\E[?7h, rmcup=, rmir=\E[4l, rmso=\E[m, rmul=\E[m,
+ sgr0=\E[m, smacs=\E(B, smam=\E[?7l,
+ smcup=\E[?20l\E[?7h\E[1Q, smir=\E[4h, smso=\E[7m,
+ smul=\E[4m, vpa=\E[%i%p1%dd,
+tvi970-vb|televideo 970 with visual bell,
+ flash=\E[?5h\0\0\0\0\0\0\0\0\0\0\0\0\0\E[?5l, use=tvi970,
+tvi970-2p|televideo 970 with using 2 pages of memory,
+ rmcup=\E[H\E[J\E[V, smcup=\E[U\E[?20l\E[?7h\E[1Q,
+ use=tvi970,
+# Works with vi and rogue. NOTE: Esc v sets autowrap on, Esc u sets 80 chars
+# per line (rather than 40), Esc K chooses the normal character set. Not sure
+# padding is needed, but adapted from the tvi920c termcap. The <smso> and
+# <smul> strings are klutzy, but at least use no screen space.
+# (tvipt: removed obsolete ":ma=^Kk^Ll^R^L:". I wish we knew <rmam>,
+# its absence means <smam>=\Ev isn't safe to use. -- esr)
+# From: Gene Rochlin <armsis@amber.berkeley.edu> 9/19/84.
+# The <ed>/<kf0>/<kf1>/<khome>/<mc4>, and <mc5> caps are from BRL, which says:
+# F1 and F2 should be programmed as ^A and ^B; required for UNIFY.
+tvipt|televideo personal terminal,
+ am,
+ cols#80, lines#24,
+ cbt=\EI, clear=^Z, cub1=^H, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dl1=\ER$<5*>,
+ ed=\EY, el=\ET, home=^^, if=/usr/share/tabset/stdcrt,
+ il1=\EE$<5*>, is2=\Ev\Eu\EK, kbs=^H, kcub1=^H, kcud1=^J,
+ kcuf1=^L, kcuu1=^K, kf0=^A, kf1=^B, khome=^^, mc4=^T, mc5=^R,
+ rmso=\EF, rmul=\EF, smso=\EG1@A\EH, smul=\EG1B@\EH,
+# From: Nathan Peterson <nathan@sco.com>, 03 Sep 1996
+tvi9065|televideo 9065,
+ am, bw, chts, hs, mc5i, mir, msgr, xenl, xon,
+ cols#80, it#8, lh#1, lines#25, lm#0, lw#9, ma#4, nlab#8, vt#0,
+ wnum#0, wsl#30,
+ acsc='r0_jhkglfmeniopqksqtmulvownxj, bel=^G,
+ blink=\EG2, bold=\EG\,, cbt=\EI, civis=\E.0, clear=^Z,
+ cnorm=\E.3, cr=^M, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD,
+ cub1=^H, cud=\E[%p1%dB, cud1=^V, cuf=\E[%p1%dC, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu=\E[%p1%dA,
+ cuu1=^K, cvvis=\E.2, dch=\E[%p1%dP, dch1=\EW, dim=\EGp,
+ dl=\E[%p1%dM, dl1=\ER, dsl=\E_30\r, ech=\E[%p1%d@, ed=\EY,
+ el=\ET, flash=\Eb$<15>\Ed, fsl=^M, home=^^, ht=^I, hts=\E1,
+ ich=\E[%p1%d@, if=/usr/share/tabset/stdcrt,
+ il=\E[%p1%dL, il1=\EE, ind=^J, indn=\E[%p1%dS, invis=\EG1,
+ ip=$<3>,
+ is1=\E"\E%\E'\E(\EG@\EO\EX\E[=5l\E[=6l\E[=7h\Ed\Er,
+ is2=\EF2\EG0\E\\L, is3=\E<\E[=4l\E[=8h, kHOM=\E\s\s\s,
+ kbs=^H, kcbt=\EI, kcub1=^H, kcud1=^V, kcuf1=^L, kcuu1=^K,
+ kdch1=\EW, kf1=^A@\r, kf10=^AI\r, kf11=^AJ\r, kf12=^AK\r,
+ kf2=^AA\r, kf3=^AB\r, kf4=^AC\r, kf5=^AD\r, kf6=^AE\r,
+ kf7=^AF\r, kf8=^AG\r, kf9=^AH\r, khome=^^, ll=\E[25;1H,
+ mc0=\E[0;0i, mc4=\Ea, mc5=\E`, nel=^M^J,
+ pfkey=\E|%p1%{48}%+%c3%p2%s\031,
+ pfloc=\E|%p1%{48}%+%c2%p2%s\031,
+ pfx=\E|%p1%{48}%+%c1%p2%s\031,
+ pln=\E_%p1%{63}%+%c%p2%s\r, prot=\E&,
+ rep=\E[%p2%db%p1%c, rev=\EG4,
+ rf=/usr/share/tabset/stdcrt, ri=\Ej, rin=\E[%p1%dT,
+ rmacs=\E%, rmam=\E[=7l, rmcup=\E.3\Er\E[1;25r\E[25;0H,
+ rmdc=\0, rmir=\Er, rmln=\E[4;1v, rmso=\EG0, rmul=\EG0,
+ rmxon=^N, rs1=\EC\EDF\E[0;0v\E[8;1v\E[=65l,
+ rs2=\E.b\E[10;20v\E[14;1v\E[3;0v\E[7;0v\E[=11.h\E[=12.h\E[=13.h\E[=14.h\E[=15l\E[=20h\E[=60l\E[=61h\E[=9l\E[=10l\E[=21l\E[=23l\E[=3l\E_40\E_50\En\Ew\Ee \Ex0\0\0\Ex1\0\0\Ex2\0\0\Ex3\0\0\Ex4\0\0\E1,
+ rs3=\E[=19h\E.3\E9\E0O\0\0\0\0\0\E0o\0\0\0\0\0\E0J\177\0\0\0\0,
+ sgr=\EG0%?%p1%t\EGt%;%?%p2%t\EG8%;%?%p3%t\EG4%;%?%p4%t\EG2%;%?%p5%t\EGp%;%?%p6%t\EG\,%;%?%p7%t\EG1%;%?%p9%t\E$%e\E%%%;,
+ sgr0=\EG0, smacs=\E$, smam=\E=7h, smcup=\E.2, smdc=\Er,
+ smir=\Eq, smln=\E[4;2v, smso=\EGt, smul=\EG8, smxon=^O,
+ tbc=\E3, tsl=\E[4;1v\E_30, uc=\EG8\EG0,
+
+#### Visual (vi)
+#
+# In September 1993, Visual Technology of Westboro, Massachusetts,
+# merged with White Pine Software of Nashua, New Hampshire.
+#
+# White Pine Software may be contacted at +1 603/886-9050.
+# Or visit White Pine on the World Wide Web at URL http://www.wpine.com.
+#
+
+# Visual 50 from Beau Shekita, BTL-Whippany <whuxlb!ejs>
+# Recently I hacked together the following termcap for Visual
+# Technology's Visual 50 terminal. It's a slight modification of
+# the vt52 termcap.
+# It's intended to run when the Visual 50 is in vt52 emulation mode
+# (I know what you're thinking; if it's emulating a vt52, then why
+# another termcap? Well, it turns out that the Visual 50 can handle
+# <dl1> and db(?) among other things, which the vt52 can't)
+# The termcap works OK for the most part. The only problem is on
+# character inserts. The whole line gets painfully redrawn for each
+# character typed. Any suggestions?
+# Beau's entry is combined with the vi50 entry from University of Wisconsin.
+# Note especially the <il1> function. <kf4>-<kf6> are really l4-l6 in
+# disguise; <kf7>-<kf9> are really l1-l3.
+vi50|visual 50,
+ am, da, db, msgr,
+ cols#80, it#8, lines#24,
+ bel=^G, cbt=\Ez$<4/>, clear=\EH\EJ, cr=^M, cub1=^H, cud1=\EB,
+ cuf1=\EC, cup=\EY%p1%{32}%+%c%p2%{32}%+%c, cuu1=\EA,
+ dl1=\EM$<3*/>, ed=\EJ, el=\EK$<16/>, home=\EH, ht=^I,
+ il1=\EL, ind=^J, kbs=^H, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kf1=\EP, kf2=\EQ, kf3=\ER, kf4=\EV, kf5=\EE,
+ kf6=\E], kf7=\EL, kf8=\Ev, kf9=\EM, khome=\EH, nel=^M^J,
+ ri=\EI, rmso=\ET, rmul=\EW, smso=\EU, smul=\ES,
+# this one was BSD & SCO's vi50
+vi50adm|visual 50 in adm3a mode,
+ am, msgr,
+ cols#80, it#8, lines#24,
+ bel=^G, clear=^Z, cr=^M, cub1=^H, cud1=^J, cuf1=^L,
+ cup=\E=%p1%{32}%+%c%p2%{32}%+%c, cuu1=^K, dl1=\EM,
+ ed=\Ek, el=\EK, home=\EH, ht=^I, il1=\EL, ind=^J, kbs=^H,
+ kcub1=\ED, kcud1=\EB, kcuf1=\EC, kcuu1=\EA, khome=\EH,
+ rmso=\ET, smso=\EU,
+# From: Jeff Siegal <jbs@athena.mit.edu>
+vi55|Visual 55,
+ am, mir, msgr,
+ cols#80, it#8, lines#24,
+ clear=\Ev, csr=\E_%p1%{65}%+%c%p2%{65}%+%c, cub1=^H,
+ cud1=^J, cuf1=\EC, cup=\EY%p1%{32}%+%c%p2%{32}%+%c,
+ cuu1=\EA, dch1=\Ew, dl1=\EM, ed=\EJ, el=\EK, home=\EH, ht=^I,
+ il1=\EL, is2=\Ev\E_AX\Eb\EW\E9P\ET, kbs=^H, kcub1=\ED,
+ kcud1=\EB, kcuf1=\EC, kcuu1=\EA, ri=\EI, rmir=\Eb, rmso=\ET,
+ smir=\Ea, smso=\EU,
+
+# Visual 200 from BRL
+# The following switch settings are assumed for normal operation:
+# FULL_DUPLEX SCROLL CR
+# AUTO_NEW_LINE_ON VISUAL_200_EMULATION_MODE
+# Other switches may be set for operator convenience or communication
+# requirements.
+# Character insertion is kludged in order to get around the "beep" misfeature.
+# (This cap is commented out because <smir>/<rmir> is more efficient -- esr)
+# Supposedly "4*" delays should be used for <il1>, <ed>, <clear>, <dch1>,
+# and <dl1> strings, but we seem to get along fine without them.
+vi200|visual 200,
+ am, mir, msgr,
+ cols#80, it#8, lines#24,
+ acsc=, bel=^G, cbt=\Ez, clear=\Ev, cnorm=\Ec, cr=^M, cub1=^H,
+ cud1=^J, cuf1=\EC, cup=\EY%p1%{32}%+%c%p2%{32}%+%c,
+ cuu1=\EA, cvvis=\Ed, dch1=\EO, dim=\E4, dl1=\EM, ed=\Ey,
+ el=\Ex, home=\EH, ht=^I, hts=\E1, il1=\EL, ind=^J, invis=\Ea,
+ kbs=^H, kclr=\Ev, kctab=\E2, kcub1=\ED, kcud1=\EB, kcuf1=\EC,
+ kcuu1=\EA, kdch1=\EO, kdl1=\EM, ked=\EJ, kel=\Et, kf0=\E?p,
+ kf1=\E?q, kf2=\E?r, kf3=\E?s, kf4=\E?t, kf5=\E?u, kf6=\E?v,
+ kf7=\E?w, kf8=\E?x, kf9=\E?y, khome=\EH, khts=\E1, kich1=\Ei,
+ kil1=\EL, krmir=\Ej, mc0=\EH\E], mc4=\EX, mc5=\EW, ri=\EI,
+ rmacs=\EG, rmkx=\E>, rmso=\E3,
+ rs1=\E3\Eb\Ej\E\El\EG\Ec\Ek\EX, sgr0=\E3\Eb, smacs=\EF,
+ smkx=\E=, smso=\E4, tbc=\Eg,
+# The older Visuals didn't come with function keys. This entry uses
+# <smkx> and <rmkx> so that the keypad keys can be used as function keys.
+# If your version of vi doesn't support function keys you may want
+# to use vi200-f.
+vi200-f|visual 200 no function keys,
+ is2=\E3\Eb\Ej\E\\\El\EG\Ed\Ek, kf0=\E?p, kf1=\E?q,
+ kf2=\E?r, kf3=\E?s, kf4=\E?t, kf5=\E?u, kf6=\E?v, kf7=\E?w,
+ kf8=\E?x, kf9=\E?y, rmkx=\E>, rmso@, smkx=\E=, smso@,
+ use=vi200,
+vi200-rv|visual 200 reverse video,
+ cnorm@, cvvis@, ri@, rmso=\E3, smso=\E4, use=vi200,
+
+# the function keys are programmable but we don't reprogram them to their
+# default values with <is2> because programming them is very verbose. maybe
+# an initialization file should be made for the 300 and they could be stuck
+# in it.
+# (vi300: added <rmam>/<smam> based on init string -- esr)
+vi300|visual 300 ansi x3.64,
+ am, bw, mir, xenl,
+ cols#80, lines#24,
+ bel=^G, cbt=\E[Z, clear=\E[H\E[2J, cr=^M, cub1=^H, cud1=\E[B,
+ cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A,
+ dch1=\E[P$<40>, dl1=\E[M, ed=\E[J, el=\E[K, home=\E[H, ht=^I,
+ il1=\E[L, ind=^J,
+ is2=\E[7s\E[2;3;4;20;?5;?6l\E[12;?7h\E[1Q\E[0;1(D\E[8s,
+ kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kf1=\E_A\E\\, kf2=\E_B\E\\, kf3=\E_C\E\\, kf4=\E_D\E\\,
+ kf5=\E_E\E\\, kf6=\E_F\E\\, kf7=\E_G\E\\, kf8=\E_H\E\\,
+ kf9=\E_I\E\\, khome=\E[H, ri=\EM, rmam=\E[?7l, rmir=\E[4l,
+ rmso=\E[m, rmul=\E[m