Attachment 214083 Details for Bug 246029 – New termcap entries

[patch] New termcap entries

termcap.diff (text/plain), 12.89 KB, created by Cy Schubert on 2020-05-04 04:25:23 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Cy Schubert

Created: 2020-05-04 04:25:23 UTC

Size: 12.89 KB

patch

obsolete

>diff --git a/share/termcap/termcap b/share/termcap/termcap
>index 46044da03c5..60cb6bc8281 100644
>--- a/share/termcap/termcap
>+++ b/share/termcap/termcap
>@@ -2788,6 +2788,276 @@ screen-256color|VT 100/ANSI X3.64 terminal with 256 colors:\
> 	:Co#256:pa#32767:\
> 	:AB=\E[48;5;%dm:AF=\E[38;5;%dm:tc=screen:
> 
>+xterm+x11mouse|X11 xterm mouse protocol:\
>+	:Km=\E[M:
>+xterm-x11mouse|X11 mouse:\
>+	:tc=xterm+x11mouse:tc=xterm:
>+
>+screen+fkeys|function-keys according to screen:\
>+	:*6@:@0@:@7=\E[4~:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:kh=\E[1~:
>+
>+screen+italics|screen cannot support italics:\
>+	:ZH@:ZR@:
>+
>+screen.xterm-xfree86|screen.xterm-new|screen customized for modern xterm:\
>+	:bw:ut@:\
>+	:#3@:%c@:%e@:mk@:ml@:mu@:rp@:\
>+	:..sa=%?%p9%t\E(0%e\E(B%;\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m:\
>+	:tc=screen+italics:tc=screen+fkeys:tc=xterm+x11mouse:\
>+	:tc=xterm-new:
>+
>+ibm+16color|IBM aixterm color definitions:\
>+	:Co#16:pa#256:\
>+	:..AB=\E[%?%p1%{8}%<%t%p1%{40}%+%e%p1%{92}%+%;%dm:\
>+	:..AF=\E[%?%p1%{8}%<%t%p1%{30}%+%e%p1%{82}%+%;%dm:\
>+	:..Sb=%p1%{8}%/%{6}%*%{4}%+\E[%d%p1%{8}%m%Pa%?%ga%{1}%=%t4%e%ga%{3}%=%t6%e%ga%{4}%=%t1%e%ga%{6}%=%t3%e%ga%d%;m:\
>+	:..Sf=%p1%{8}%/%{6}%*%{3}%+\E[%d%p1%{8}%m%Pa%?%ga%{1}%=%t4%e%ga%{3}%=%t6%e%ga%{4}%=%t1%e%ga%{6}%=%t3%e%ga%d%;m:
>+xterm+256setaf|xterm 256-color (set-only):\
>+	:cc@:\
>+	:Co#256:pa#65536:\
>+	:AB=\E[48;5;%dm:AF=\E[38;5;%dm:Ic@:Sb@:Sf@:op=\E[39;49m:
>+
>+# ======================================================================
>+# Entries for GNU Screen with 16 colors.
>+# Those variations permit to benefit from 16 colors palette, and from
>+# bold font and blink attribute separated from bright colors. But they
>+# are less portable than the generic "screen" 8 color entries: Their
>+# usage makes real sense only if the terminals you attach and reattach
>+# do all support 16 color palette.
>+
>+screen-16color|GNU Screen with 16 colors:\
>+	:tc=ibm+16color:tc=screen:
>+
>+screen-16color-s|GNU Screen with 16 colors and status line:\
>+	:tc=ibm+16color:tc=SH:
>+
>+screen-16color-bce|GNU Screen with 16 colors and BCE:\
>+	:tc=ibm+16color:tc=screen-bce:
>+
>+screen-16color-bce-s|GNU Screen with 16 colors using BCE and status line:\
>+	:ut:tc=ibm+16color:tc=SH:
>+
>+# ======================================================================
>+# Entries for GNU Screen 4.02 with --enable-colors256.
>+
>+screen-256color-s|GNU Screen with 256 colors and status line:\
>+	:tc=xterm+256setaf:tc=SH:
>+
>+screen-256color-bce|GNU Screen with 256 colors and BCE:\
>+	:ut:tc=xterm+256setaf:tc=screen-bce:
>+
>+screen-256color-bce-s|GNU Screen with 256 colors using BCE and status line:\
>+	:ut:tc=xterm+256setaf:tc=SH:
>+
>+screen.xterm-256color|GNU Screen with xterm using 256 colors:\
>+	:tc=xterm+256setaf:tc=screen.xterm-new:
>+
>+screen.putty-256color|GNU Screen with putty using 256 colors:\
>+	:tc=xterm+256setaf:tc=screen.putty:
>+
>+screen.xterm-r6|screen customized for X11R6 xterm:\
>+	:bw:tc=xterm+x11mouse:tc=screen+fkeys:tc=xterm-r6:
>+# Color applications running in screen and TeraTerm do not play well together
>+# on Solaris because Sun's curses implementation gets confused.
>+screen.teraterm|disable ncv in teraterm:\
>+	:NC#127:\
>+	:ac=+\020,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376:\
>+	:tc=screen+fkeys:tc=xterm+x11mouse:tc=screen:
>+
>+#### DEC VT100 and compatibles
>+#
>+# DEC terminals from the vt100 forward are collected here. Older DEC terminals
>+# and micro consoles can be found in the `obsolete' section.  More details on
>+# the relationship between the VT100 and ANSI X3.64/ISO 6429/ECMA-48 may be
>+# found near the end of this file.
>+#
>+# Except where noted, these entries are DEC's official terminfos.
>+# Contact Bill Hedberg <hedberg@hannah.enet.dec.com> of Terminal Support
>+# Engineering for more information.  Updated terminfos and termcaps
>+# are kept available at ftp://gatekeeper.dec.com/pub/DEC/termcaps.
>+#
>+# In October 1995 DEC sold its terminals business, including the VT and Dorio
>+# line and trademark, to SunRiver Data Systems.  SunRiver has since changed
>+# its name to Boundless Technologies; see http://www.boundless.com.
>+#
>+
>+# NOTE:  Any VT100 emulation, whether in hardware or software, almost
>+# certainly includes what DEC called the `Level 1 editing extension' codes;
>+# only the very oldest VT100s lacked these and there probably aren't any of
>+# those left alive.  To capture these, use one of the VT102 entries.
>+#
>+# Note that the :xn: glitch in vt100 is not quite the same as on the Concept,
>+# since the cursor is left in a different position while in the
>+# weird state (concept at beginning of next line, vt100 at end
>+# of this line) so all versions of vi before 3.7 don't handle
>+# :xn: right on vt100. The correct way to handle :xn: is when
>+# you output the char in column 80, immediately output CR LF
>+# and then assume you are in column 1 of the next line. If :xn:
>+# is on, am should be on too.
>+#
>+# I assume you have smooth scroll off or are at a slow enough baud
>+# rate that it doesn't matter (1200? or less). Also this assumes
>+# that you set auto-nl to "on", if you set it off use vt100-nam
>+# below.
>+#
>+# The padding requirements listed here are guesses. It is strongly
>+# recommended that xon/xoff be enabled, as this is assumed here.
>+#
>+# The vt100 uses <rs2> and <rf> rather than :is:/:ct:/:st: because the
>+# tab settings are in non-volatile memory and don't need to be
>+# reset upon login. Also setting the number of columns glitches
>+# the screen annoyingly. You can type "reset" to get them set.
>+#
>+# The VT100 series terminals have cursor ("arrows") keys which can operate
>+# in two different modes: Cursor Mode and Application Mode.  Cursor Mode
>+# is the reset state, and is assumed to be the normal state.  Application
>+# Mode is the "set" state.  In Cursor Mode, the cursor keys transmit
>+# "Esc [ {code}" sequences, conforming to ANSI standards.  In Application
>+# Mode, the cursor keys transmit "Esc O <code>" sequences.  Application Mode
>+# was provided primarily as an aid to the porting of VT52 applications.  It is
>+# assumed that the cursor keys are normally in Cursor Mode, and expected that
>+# applications such as vi will always transmit the :ks: string.  Therefore,
>+# the definitions for the cursor keys are made to match what the terminal
>+# transmits after the :ks: string is transmitted.  If the :ks: string
>+# is a null string or is not defined, then cursor keys are assumed to be in
>+# "Cursor Mode", and the cursor keys definitions should match that assumption,
>+# else the application may fail.  It is also expected that applications will
>+# always transmit the :ke: string to the terminal before they exit.
>+#
>+# The VT100 series terminals have an auxiliary keypad, commonly referred to as
>+# the "Numeric Keypad", because it is a cluster of numeric and function keys.
>+# The Numeric Keypad which can operate in two different modes: Numeric Mode and
>+# Application Mode.  Numeric Mode is the reset state, and is assumed to be
>+# the normal state.  Application Mode is the "set" state.  In Numeric Mode,
>+# the numeric and punctuation keys transmit ASCII 7-bit characters, and the
>+# Enter key transmits the same as the Return key (Note: the Return key
>+# can be configured to send either LF (\015) or CR LF).  In Application Mode,
>+# all the keypad keys transmit "Esc O {code}" sequences.  The PF1 - PF4 keys
>+# always send the same "Esc O {code}" sequences.  It is assumed that the keypad
>+# is normally in Numeric Mode.  If an application requires that the keypad be
>+# in Application Mode then it is expected that the user, or the application,
>+# will set the TERM environment variable to point to a terminfo entry which has
>+# defined the :ks: string to include the codes that switch the keypad into
>+# Application Mode, and the terminfo entry will also define function key
>+# fields to match the Application Mode control codes.  If the :ks: string
>+# is a null string or is not defined, then the keypad is assumed to be in
>+# Numeric Mode.  If the :ks: string switches the keypad into Application
>+# Mode, it is expected that the :ke: string will contain the control codes
>+# necessary to reset the keypad to "Normal" mode, and it is also expected that
>+# applications which transmit the :ks: string will also always transmit the
>+# :ke: string to the terminal before they exit.
>+#
>+# Here's a diagram of the VT100 keypad keys with their bindings.
>+# The top line is the name of the key (some DEC keyboards have the keys
>+# labelled somewhat differently, like GOLD instead of PF1, but this is
>+# the most "official" name).  The second line is the escape sequence it
>+# generates in Application Keypad mode (where "$" means the ESC
>+# character).  The third line contains two items, first the mapping of
>+# the key in terminfo, and then in termcap.
>+#   _______________________________________
>+#  |   PF1   |   PF2   |   PF3   |   PF4   |
>+#  |   $OP   |   $OQ   |   $OR   |   $OS   |
>+#  |_kf1__k1_|_kf2__k2_|_kf3__k3_|_kf4__k4_|
>+#  |    7         8         9         -    |
>+#  |   $Ow   |   $Ox   |   $Oy   |   $Om   |
>+#  |_kf9__k9_|_kf10_k;_|_kf0__k0_|_________|
>+#  |    4    |    5    |    6    |    ,    |
>+#  |   $Ot   |   $Ou   |   $Ov   |   $Ol   |
>+#  |_kf5__k5_|_kf6__k6_|_kf7__k7_|_kf8__k8_|
>+#  |    1    |    2    |    3    |         |
>+#  |   $Oq   |   $Or   |   $Os   |  enter  |
>+#  |_ka1__K1_|_kb2__K2_|_ka3__K3_|  $OM    |
>+#  |         0         |   .     |         |
>+#  |        $Op        |  $On    |         |
>+#  |___kc1_______K4____|_kc3__K5_|_kent_@8_|
>+#
>+# Note however, that the arrangement of the 5-key ka1-kc3 do not follow the
>+# terminfo guidelines.  That is a compromise used to assign the remaining
>+# keys on the keypad to kf5-kf0, used on older systems with legacy termcap
>+# support:
>+vt100+keypad|dec vt100 numeric keypad no fkeys:\
>+	:K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:
>+screen.Eterm|screen in Eterm:\
>+	:tc=xterm+x11mouse:tc=screen+fkeys:tc=Eterm:
>+
>+# fix the backspace key
>+screen.linux|screen in linux console:\
>+	:bw:\
>+	:kB@:kb=\177:tc=xterm+x11mouse:tc=screen+fkeys:tc=screen:
>+
>+screen.putty|screen in putty:\
>+	:tc=xterm+x11mouse:tc=screen+fkeys:tc=putty:
>+
>+# The default "screen" entry is reasonably portable, but not optimal for the
>+# most widely-used terminal emulators.  The "bce" capability is supported in
>+# screen since 3.9.13, and when used, will require fewer characters to be sent
>+# to the terminal for updates.
>+#
>+# If you are using only terminals which support bce, then you can use this
>+# feature in your screen configuration.
>+#
>+# Adding these lines to your ".screenrc" file will allow using these customized
>+# entries:
>+#	term screen-bce
>+#	bce on
>+#	defbce on
>+screen-bce.xterm-new|screen optimized for modern xterm:\
>+	:ut:\
>+	:ec@:tc=screen+italics:tc=screen.xterm-new:
>+screen-bce.Eterm|screen optimized for Eterm:\
>+	:ut:\
>+	:ec@:tc=screen.Eterm:
>+screen-bce.linux|screen optimized for linux console:\
>+	:ut:\
>+	:ec@:tc=screen.linux:
>+
>+screen2|old VT 100/ANSI X3.64 virtual terminal:\
>+	:co#80:it#8:li#24:\
>+	:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
>+	:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:al=\E[L:bt=\E[Z:cd=\E[J:\
>+	:ce=\E[K:cl=\E[2J\E[H:cm=\E[%i%d;%dH:cr=\r:ct=\E[3g:\
>+	:dc=\E[P:dl=\E[M:do=\E[B:ei=\E[4l:ic=:im=\E[4h:k0=\E~:\
>+	:k1=\ES:k2=\ET:k3=\EU:k4=\EV:k5=\EW:k6=\EP:k7=\EQ:k8=\ER:\
>+	:k9=\E0I:kb=^H:kd=\EB:kh=\EH:kl=\ED:kr=\EC:ku=\EA:le=^H:\
>+	:me=\E[m:nd=\E[C:nw=\r\n:r1=\Ec:rc=\E8:sc=\E7:se=\E[23m:\
>+	:sf=\n:so=\E[3m:sr=\EM:st=\EH:ta=^I:ue=\E[24m:up=\E[A:\
>+	:us=\E[4m:
>+# (screen3: removed unknown ":xv:LP:G0:" -- esr)
>+screen3|older VT 100/ANSI X3.64 virtual terminal:\
>+	:km:mi:ms:\
>+	:co#80:it#8:li#24:\
>+	:AL=\E[%dL:DC=\E[%dP:DL=\E[%dM:DO=\E[%dB:IC=\E[%d@:\
>+	:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:al=\E[L:bl=^G:bt=\E[Z:\
>+	:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:cr=\r:\
>+	:cs=\E[%i%d;%dr:ct=\E[3g:dc=\E[P:dl=\E[M:do=\n:ei=\E[4l:\
>+	:ho=\E[H:im=\E[4h:is=\E)0:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
>+	:kb=^H:kd=\EOB:ke=\E>:kl=\EOD:kr=\EOC:ks=\E=:ku=\EOA:le=^H:\
>+	:mb=\E[5m:md=\E[1m:me=\E[m:mr=\E[7m:nd=\E[C:nw=\EE:r1=\Ec:\
>+	:rc=\E8:sc=\E7:se=\E[23m:sf=\n:so=\E[3m:sr=\EM:st=\EH:ta=^I:\
>+	:ue=\E[24m:up=\EM:us=\E[4m:
>+
>+# screen 4.0 was released 2003-07-21, and as of March 2019, its terminfo file
>+# was last updated in 2009 to include 256-color support.  The most recent
>+# release is 4.6.2 (October 2017).
>+screen4:\
>+	:tc=screen:
>+
>+# As of March 2019, screen 5.0 has not been released.
>+#
>+# However,
>+#
>+#	https://savannah.gnu.org/bugs/?36676
>+#
>+# mentions a change to implement italics which should be in a version 5,
>+# (implemented 2016-11-05, but merged 2017-07-09).  That does away with the
>+# longstanding use of SGR 3 for standout, and interprets it as italics.
>+#
>+# The same development branch has some support for direct-colors, but none
>+# of this has been documented.
>+screen5|VT 100/ANSI X3.64 virtual terminal (someday):\
>+	:..sa=\E[0%?%p6%t;1%;%?%p2%t;4%;%?%p1%p3%|%t;7%;%?%p4%t;5%;%?%p5%t;2%;m%?%p9%t\016%e\017%;:\
>+	:se=\E[27m:so=\E[7m:tc=ecma+italics:tc=screen:
>+
> ecma+italics|ECMA-48 italics:\
> 	:ZH=\E[3m:ZR=\E[23m:
>

Actions: View | Diff

Attachments on bug 246029: 214083 | 214116