##############################################################################
-# Copyright (c) 2001-2016,2019 Free Software Foundation, Inc. #
+# Copyright 2019-2020,2021 Thomas E. Dickey #
+# Copyright 2001-2015,2016 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"), #
#
# Author: Thomas Dickey
#
-# $Id: Caps.uwin,v 1.9 2019/04/13 19:55:29 tom Exp $
+# $Id: Caps.uwin,v 1.15 2021/10/08 07:55:48 tom Exp $
#
# This is an adaptation of ncurses' termcap/terminfo capability table, which
# is designed to align with U/Win's terminfo.
#
# The codes following [Y-] in column 7 describe the versions of termcap which
# use the given capability. This information is not used by the curses library
-# proper; rather, it's there to help the terminfo maintainer avoid emitting
+# proper; rather, it is there to help the terminfo maintainer avoid emitting
# termcap entry translations that are more than 1023 bytes long (and tank a
# lot of old termcap-using programs). The codes read as follows:
# B = mentioned in the BSD man page for 4.4BSD curses
# 3. List it in the standard table. You almost certainly do *not* want
# to do this -- the capabilities in that one, and their order, have been
# carefully chosen to be SVr4-binary-compatible when they're written out
-# as a terminfo object, and breaking this would be bad. It's up to the ncurses
-# library what to do with the terminfo data after it's read in.
+# as a terminfo object, and breaking this would be bad. It is up to the ncurses
+# library what to do with the terminfo data after it is read in.
#
# 4. List it in the aliases table with an IGNORE target field. If you
# do this, the capability will be ignored on input (though the user will
# 5. List it in the extensions table. If you do this, the compiler will
# silently accept the capability, but the curses library proper will never
# see it (because it won't be written out as part of the terminfo object
-# format). It's up to you what you have the compiler do with it.
+# format). It is up to you what you have the compiler do with it.
#
# There are two opposite reasons to choose option 5. One is when you want
# to eat the capability silently and discard it when doing translations
#%indicates that padding may be specified
#%.TP
#%#[1-9]
-#%in the description field indicates that the string is passed through tparm with
-#%parms as given (#\fIi\fP).
+#%in the description field indicates that the string is passed
+#%through \fBtparm\fP(3X) with parameters as given (#\fIi\fP).
+#%.IP
+#%If no parameters are listed in the description,
+#%passing the string through \fBtparm\fP(3X) may give unexpected results,
+#%e.g., if it contains percent (%%) signs.
#%.TP
#%(P*)
#%indicates that padding may vary in proportion to the number of
key_f63 kf63 str Fr KEY_F(63) - ----E F63 function key
clr_bol el1 str cb - - ----- Clear to beginning of line
clear_margins mgc str MC - - ----- clear right and left soft margins
-set_left_margin smgl str ML - - ----- set left soft margin at current column. See smgl. (ML is not in BSD termcap).
+set_left_margin smgl str ML - - ----- set left soft margin at current column. (ML is not in BSD termcap).
set_right_margin smgr str MR - - ----- set right soft margin at current column
device_type devt str dv - - ----- Indicate language/codeset support
code_set_init csin str ci - - ----- Init sequence for multiple codesets
# comma-separated list of capabilities for which there are corresponding keys.
# The `kn' code is accepted but ignored.
#
-# The `ma' capability seems to have been designed to map between the rogue(2)
-# motion keys (including jkhl) and characters emitted by arrow keys on some
-# primitive pre-ANSI terminals. It's so obsolete it's fossilized...
+# The `ma' capability was a 4.0BSD feature used by vi version 2.
+# It consists of pairs of characters corresponding to kl, kr, ku, kd, and kh.
+# Besides being obsolete, that interpretation conflicts with max_attributes.
#
# Here is a description of memory_lock_above and memory_unlock:
# "You can 'freeze' data on the screen by turning on Memory Lock in a line of
# vertical_tab_delay OTdV num dV - - -B--- padding required for ^V
number_of_function_keys OTkn num kn - - -B-G- count of function keys
other_non_function_keys OTko str ko - - -B-G- list of self-mapped keycaps
-arrow_key_map OTma str ma - - YBC-- map arrow keys rogue(1) motion keys
+arrow_key_map OTma str ma - - YBC-- map motion-keys for vi version 2
# memory_lock_above OTml str ml - - -B--- lock visible screen memory above the current line
# memory_unlock OTmu str mu - - -B--- unlock visible screen memory above the current line
has_hardware_tabs OTpt bool pt - - YB--- has 8-char tabs invoked with ^I
return_does_clr_eol OTxr bool xr - - YB--- return clears the line
# tek_4025_insert_line OTxx bool xx - - -BC-- Tektronix 4025 insert-line glitch
#
-# mytinfo described this as a termcap capability, but it's not listed in the
+# mytinfo described this as a termcap capability, but it is not listed in the
# 4.4BSD man pages, and not found in the 4.4BSD termcap file. The ncurses
# package, like System V, behaves as though it is always true.
#
projects / ncurses.git / blobdiff