diff options
Diffstat (limited to 'doc/html/man/user_caps.5.html')
| -rw-r--r-- | doc/html/man/user_caps.5.html | 383 |
1 files changed, 193 insertions, 190 deletions
diff --git a/doc/html/man/user_caps.5.html b/doc/html/man/user_caps.5.html index 10b6f77649da..5b00603fda2f 100644 --- a/doc/html/man/user_caps.5.html +++ b/doc/html/man/user_caps.5.html @@ -1,7 +1,7 @@ <!-- * t **************************************************************************** - * Copyright 2018-2023,2024 Thomas E. Dickey * + * Copyright 2018-2024,2025 Thomas E. Dickey * * Copyright 2017 Free Software Foundation, Inc. * * * * Permission is hereby granted, free of charge, to any person obtaining a * @@ -28,25 +28,23 @@ * sale, use or other dealings in this Software without prior written * * authorization. * **************************************************************************** - * @Id: user_caps.5,v 1.49 2024/03/16 15:35:01 tom Exp @ + * @Id: user_caps.5,v 1.60 2025/11/12 01:01:01 tom Exp @ --> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"> <HTML> <HEAD> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="generator" content="Manpage converted by man2html - see https://invisible-island.net/scripts/readme.html#others_scripts"> -<TITLE>user_caps 5 2024-03-16 ncurses 6.5 File formats</TITLE> +<TITLE>user_caps 5 2025-11-11 ncurses 6.6 File formats</TITLE> <link rel="author" href="mailto:bug-ncurses@gnu.org"> </HEAD> <BODY> -<H1 class="no-header">user_caps 5 2024-03-16 ncurses 6.5 File formats</H1> +<H1 class="no-header">user_caps 5 2025-11-11 ncurses 6.6 File formats</H1> <PRE> <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG> File formats <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG> - - </PRE><H2><a name="h2-NAME">NAME</a></H2><PRE> user_caps - user-defined <EM>terminfo</EM> capability format @@ -60,225 +58,231 @@ </PRE><H2><a name="h2-DESCRIPTION">DESCRIPTION</a></H2><PRE> </PRE><H3><a name="h3-Background">Background</a></H3><PRE> - Before <EM>ncurses</EM> 5.0, terminfo databases used a <EM>fixed</EM> <EM>repertoire</EM> of - terminal capabilities designed for the SVr2 terminal database in 1984, - and extended in stages through SVr4 (1989), and standardized in the - Single Unix Specification beginning in 1995. - - Most of the <EM>extensions</EM> in this fixed repertoire were additions to the - tables of Boolean, numeric and string capabilities. Rather than change - the meaning of an existing capability, a new name was added. The - terminfo database uses a binary format; binary compatibility was - ensured by using a header which gave the number of items in the tables - for each type of capability. The standardization was incomplete: - - <STRONG>o</STRONG> The <EM>binary</EM> <EM>format</EM> itself is not described in the X/Open Curses - documentation. Only the <EM>source</EM> <EM>format</EM> is described. - - Library developers rely upon the SVr4 documentation, and reverse- - engineering the compiled terminfo files to match the binary format. + Prior to <EM>ncurses</EM> 5.0 (1999), <EM>terminfo</EM> databases used a <EM>fixed</EM> <EM>repertoire</EM> + of terminal capabilities designed for the SVr2 terminal database in + 1984, added to in stages through SVr4 (1989), and standardized in + X/Open Curses starting in 1995. + + Most such additions to this fixed repertoire suppelmented the tables of + Boolean, numeric, and string capabilities. Rather than changing the + meaning of an existing capability, a new name was added. The <EM>terminfo</EM> + database uses a binary format; binary compatibility was ensured by + using a header that counted the number of items in the tables for each + type of capability. Because each <EM>curses</EM> vendor extended the standard + capability lists in distinct ways, a library could be programmed to + recognize only compiled <EM>terminfo</EM> entries that it was prepared to + interpret. Standardization was incomplete. + + <STRONG>o</STRONG> X/Open Curses describes only the <EM>source</EM> format, not its <EM>binary</EM> + representation on disk. + + Library developers rely upon SVr4 documentation and reverse + engineering of compiled <EM>terminfo</EM> files to match the binary format. <STRONG>o</STRONG> Lacking a standard for the binary format, most implementations copy the SVr2 binary format, which uses 16-bit signed integers, and is limited to 4096-byte entries. - The format cannot represent very large numeric capabilities, nor - can it represent large numbers of special keyboard definitions. + The SVr2 format cannot represent very large numeric capability + values, nor can it represent large numbers of key definitions, as + are required to distinguish multiple modifier keys used in + combination with a function key. <STRONG>o</STRONG> The tables of capability names differ between implementations. - Although they <EM>may</EM> provide all of the standard capability names, the - position in the tables differs because some features were added as - needed, while others were added (out of order) to comply with - X/Open Curses. + Although they <EM>may</EM> provide all of the standard capability names, + each arranges its table entries differently because some features + were added as needed, while others were added -- out of order -- + for X/Open Curses conformance. - While <EM>ncurses</EM>' repertoire of predefined capabilities is closest to - Solaris, Solaris's terminfo database has a few differences from the - list published by X/Open Curses. For example, <EM>ncurses</EM> can be - configured with tables which match the terminal databases for AIX, - HP-UX or OSF/1, rather than the default Solaris-like configuration. + While <EM>ncurses</EM>'s capability repertoire is closest to that of + Solaris, the set of capabilities supported by each vendor's <EM>term-</EM> + <EM>info</EM> database differs from the list published by X/Open Curses. + <EM>ncurses</EM> can be configured with tables that match the terminal + databases for AIX, HP-UX, or OSF/1, rather than the default + Solaris-like configuration. - <STRONG>o</STRONG> In SVr4 curses and <EM>ncurses</EM>, the terminal database is defined at - compile-time using a text file which lists the different terminal - capabilities. + <STRONG>o</STRONG> In SVr4 <EM>curses</EM> and <EM>ncurses</EM>, the terminal database is defined at + compile time by interpolating a text file that lists the different + terminal capabilities. - In principle, the text-file can be extended, but doing this - requires recompiling and reinstalling the library. The text-file - used in <EM>ncurses</EM> for terminal capabilities includes details for - various systems past the documented X/Open Curses features. For - example, <EM>ncurses</EM> supports these capabilities in each configuration: + In principle, the text file can be extended, but doing so requires + recompiling and reinstalling the library. The text file used by + <EM>ncurses</EM> for terminal capabilities includes details of extensions to + X/Open Curses made by various systems. For example, <EM>ncurses</EM> + supports the following nonstandard capabilities in each + configuration. - memory_lock - (meml) lock memory above cursor + <STRONG>memory_lock</STRONG> + (<STRONG>meml</STRONG>) lock memory above cursor - memory_unlock - (memu) unlock memory + <STRONG>memory_unlock</STRONG> + (<STRONG>memu</STRONG>) unlock memory - box_chars_1 - (box1) box characters primary set + <STRONG>box_chars_1</STRONG> + (<STRONG>box1</STRONG>) box characters primary set The memory lock/unlock capabilities were included because they were - used in the X11R6 terminal description for <STRONG>xterm(1)</STRONG>. The <EM>box1</EM> - capability is used in tic to help with terminal descriptions - written for AIX. + used in the X11R6 terminal description for <STRONG>xterm(1)</STRONG>. <STRONG>tic</STRONG> uses the + <STRONG>box1</STRONG> capability to cope with terminal descriptions written for AIX. - During the 1990s, some users were reluctant to use terminfo in spite of - its performance advantages over termcap: + During the 1990s, some application developers were reluctant to use + <EM>terminfo</EM> in spite of its performance (and other) advantages over + <EM>termcap</EM>. - <STRONG>o</STRONG> The fixed repertoire prevented users from adding features for - unanticipated terminal improvements (or required them to reuse - existing capabilities as a workaround). + <STRONG>o</STRONG> The fixed repertoire prevented users from adding support for + terminal features unanticipated by X/Open Curses (or required them + to reuse existing capabilities as a workaround). <STRONG>o</STRONG> The limitation to 16-bit signed integers was also mentioned. - Because termcap stores everything as a string, it could represent + Because <EM>termcap</EM> stores everything as a string, it could represent larger numbers. - Although termcap's extensibility was rarely used (it was never the - <EM>speaker</EM> who had actually used the feature), the criticism had a point. - <EM>ncurses</EM> 5.0 provided a way to detect nonstandard capabilities, - determine their type and optionally store and retrieve them in a way - which did not interfere with other applications. These are referred to - as <EM>user-defined</EM> <EM>capabilities</EM> because no modifications to the toolset's - predefined capability names are needed. - - The <EM>ncurses</EM> utilities <STRONG>tic</STRONG> and <STRONG>infocmp</STRONG> have a command-line option "-x" - to control whether the nonstandard capabilities are stored or - retrieved. A library function <STRONG>use_extended_names</STRONG> is provided for the + Although <EM>termcap</EM>'s extensibility was rarely used -- the claimant was + never an implementor who had actually exercised it -- the criticism had + a point. <EM>ncurses</EM> 5.0 provided a way to detect nonstandard + capabilities, to determine their type, and to optionally store and + retrieve them in a way that did not interfere with other applications. + <EM>ncurses</EM> terms these <EM>user-defined</EM> <EM>capabilities</EM> because no modifications + to the standard capability list are needed. + + The <EM>ncurses</EM> utilities <STRONG>tic</STRONG> and <STRONG>infocmp</STRONG> have a command-line option "-x" + to control whether the nonstandard capabilities are stored or + retrieved. <EM>ncurses</EM> provides <STRONG><A HREF="curs_extend.3x.html">use_extended_names(3x)</A></STRONG> to programs for the same purpose. - When compiling a terminal database, if "-x" is set, <STRONG>tic</STRONG> will store a - user-defined capability if the capability name is not one of the - predefined names. + When compiling a terminal database, if "-x" is used, <STRONG>tic</STRONG> stores a user- + defined capability if the capability name is not standard. - Because <EM>ncurses</EM> provides a termcap library interface, these user- - defined capabilities may be visible to termcap applications: + Because <EM>ncurses</EM> provides a <EM>termcap</EM> library interface, these user- + defined capabilities may be visible to <EM>termcap</EM> applications. - <STRONG>o</STRONG> The termcap interface (like all implementations of termcap) - requires that the capability names are 2-characters. + <STRONG>o</STRONG> The <EM>termcap</EM> interface (like all implementations of <EM>termcap</EM>) + restricts capability names to two characters. - When the capability is simple enough for use in a termcap - application, it is provided as a 2-character name. + When the capability is simple enough for use in a <EM>termcap</EM> + application, it is provided as a two-character name. - <STRONG>o</STRONG> There are other user-defined capabilities which refer to features - not usable in termcap, e.g., parameterized strings that use more - than two parameters or use more than the trivial expression support - provided by termcap. For these, the terminfo database should have - only capability names with 3 or more characters. + <STRONG>o</STRONG> Other user-defined capabilities employ features not usable in + <EM>termcap</EM>, such as parameterized strings that use more than two + parameters or require more powerful expressions than <EM>termcap</EM> + supports. Such capabilities should, in the <EM>terminfo</EM> database, have + names at least three characters in length. <STRONG>o</STRONG> Some terminals can send distinct strings for special keys (cursor-, keypad- or function-keys) depending on modifier keys (shift, - control, etc.). While terminfo and termcap have a set of 60 - predefined function-key names, to which a series of keys can be - assigned, that is insufficient for more than a dozen keys - multiplied by more than a couple of modifier combinations. The - <EM>ncurses</EM> database uses a convention based on <STRONG>xterm(1)</STRONG> to provide - extended special-key names. + control, etc.). While <EM>terminfo</EM> and <EM>termcap</EM> define a set of sixty + function key names, to which a series of keys can be assigned, that + is insufficient for more than a dozen keys multiplied by more than + a couple of modifier combinations. The <EM>ncurses</EM> database uses a + convention based on <STRONG>xterm(1)</STRONG> to provide extended special-key names. - Fitting that into termcap's limitation of 2-character names would - be pointless. These extended keys are available only with - terminfo. + Fitting that into <EM>termcap</EM>'s limitation of 2-character names would + be pointless. These extended keys are available only with <EM>term-</EM> + <EM>info</EM>. </PRE><H3><a name="h3-Recognized-Capabilities">Recognized Capabilities</a></H3><PRE> - The <EM>ncurses</EM> library uses the user-definable capabilities. While the - terminfo database may have other extensions, <EM>ncurses</EM> makes explicit - checks for these: + The <EM>ncurses</EM> library employs user-definable capabilities. While the + <EM>terminfo</EM> database may have other extensions, <EM>ncurses</EM> makes explicit + checks for the following. - AX <EM>Boolean</EM>, asserts that the terminal interprets SGR 39 and SGR 49 - by resetting the foreground and background color, respectively, + <STRONG>AX</STRONG> (Boolean) asserts that the terminal interprets SGR 39 and SGR 49 + by resetting the foreground and background colors, respectively, to the default. - This is a feature recognized by the <STRONG>screen</STRONG> program as well. + <STRONG>screen(1)</STRONG> recognizes this capability as well. - E3 <EM>string</EM>, tells how to clear the terminal's scrollback buffer. - When present, the <STRONG><A HREF="clear.1.html">clear(1)</A></STRONG> program sends this before clearing the - terminal. + <STRONG>E3</STRONG> (string) tells an application how to clear the terminal's + scrollback buffer. When present, the <STRONG><A HREF="clear.1.html">clear(1)</A></STRONG> program sends this + before clearing the terminal. The command "<STRONG>tput</STRONG> <STRONG>clear</STRONG>" does the same thing. - NQ <EM>Boolean</EM>, used to suppress a consistency check in tic for the - <EM>ncurses</EM> capabilities in user6 through user9 (u6, u7, u8 and u9) - which tell how to query the terminal's cursor position and its + <STRONG>NQ</STRONG> (Boolean) suppresses a consistency check in <STRONG>tic</STRONG> for the <EM>ncurses</EM> + string capabilities <STRONG>user6</STRONG> (<STRONG>u6</STRONG>) through <STRONG>user9</STRONG> (<STRONG>u9</STRONG>), which tell an + application how to query the terminal's cursor position and its device attributes. - RGB - <EM>Boolean</EM>, <EM>number</EM> <STRONG>or</STRONG> <EM>string</EM>, used to assert that the - <STRONG>set_a_foreground</STRONG> and <STRONG>set_a_background</STRONG> capabilities correspond to - <EM>direct</EM> <EM>colors</EM>, using an RGB (red/green/blue) convention. This - capability allows the <STRONG>color_content</STRONG> function to return - appropriate values without requiring the application to - initialize colors using <STRONG>init_color</STRONG>. + <STRONG>RGB</STRONG> + (Boolean, numeric, or string) asserts that the <STRONG>set_a_foreground</STRONG> + (<STRONG>setaf</STRONG>) and <STRONG>set_a_background</STRONG> (<STRONG>setab</STRONG>) capabilities employ <EM>direct</EM> + <EM>colors</EM>, using an RGB (red/green/blue) convention. This + capability allows <STRONG><A HREF="curs_color.3x.html">color_content(3x)</A></STRONG> to return appropriate values + without requiring the application to initialize colors using + <STRONG><A HREF="curs_color.3x.html">init_color(3x)</A></STRONG>. - The capability type determines the values which <EM>ncurses</EM> sees: + The capability type determines the values <EM>ncurses</EM> sees. - <EM>Boolean</EM> - implies that the number of bits for red, green and blue are - the same. Using the maximum number of colors, <EM>ncurses</EM> adds - two, divides that sum by three, and assigns the result to red, - green and blue in that order. + Boolean + implies that the number of bits for red, green, and blue are + the same. Starting with the value of the capability + <STRONG>max_colors</STRONG> (<STRONG>colors</STRONG>; <EM>termcap:</EM> <STRONG>co</STRONG>), <EM>ncurses</EM> adds two, divides + the sum by three, and assigns the result to red, green, and + blue, in that order. If the number of bits needed for the number of colors is not a - multiple of three, the blue (and green) components lose in + multiple of three, the blue (and green) color channels lose in comparison to red. - <EM>number</EM> - tells <EM>ncurses</EM> what result to add to red, green and blue. If + numeric + tells <EM>ncurses</EM> what result to add to red, green, and blue. If <EM>ncurses</EM> runs out of bits, blue (and green) lose just as in the - <EM>Boolean</EM> case. + Boolean case. - <EM>string</EM> - explicitly list the number of bits used for red, green and - blue components as a slash-separated list of decimal integers. + string + specify the quantity of bits used for red, green, and blue + color channels as a slash-separated list of decimal integers. - Because there are several RGB encodings in use, applications - which make assumptions about the number of bits per color are - unlikely to work reliably. As a trivial case, for example, one - could define <STRONG>RGB#1</STRONG> to represent the standard eight ANSI colors, - i.e., one bit per color. + Because there are several RGB encodings in use, applications that + make assumptions about the number of bits per color channel are + unlikely to work reliably. As a trivial case, one could define + <STRONG>RGB#1</STRONG> to represent the standard eight ANSI X3.64/ECMA-48/ISO 6429 + colors using one bit per color channel. - U8 <EM>number</EM>, asserts that <EM>ncurses</EM> must use Unicode values for line- - drawing characters, and that it should ignore the alternate - character set capabilities when the locale uses UTF-8 encoding. - For more information, see the discussion of <STRONG>NCURSES_NO_UTF8_ACS</STRONG> - in <STRONG><A HREF="ncurses.3x.html">ncurses(3x)</A></STRONG>. + <STRONG>U8</STRONG> (numeric) asserts whether <EM>ncurses</EM> must use Unicode values for + line-drawing characters, and that it should ignore the alternate + character set (ACS) capabilities when the locale uses UTF-8 + encoding. See the discussion of <STRONG>NCURSES_NO_UTF8_ACS</STRONG> in section + "ENVIRONMENT" of <STRONG><A HREF="ncurses.3x.html">ncurses(3x)</A></STRONG>. Set this capability to a nonzero value to enable it. - XM <EM>string</EM>, override <EM>ncurses</EM>'s built-in string which enables/disables - <STRONG>xterm(1)</STRONG> mouse mode. + <STRONG>XM</STRONG> (string) override <EM>ncurses</EM>'s built-in string that directs <STRONG>xterm(1)</STRONG> + to enable or disable mouse mode. <EM>ncurses</EM> sends a character sequence to the terminal to initialize mouse mode, and when the user clicks the mouse buttons or (in certain modes) moves the mouse, handles the characters sent back - by the terminal to tell it what was done with the mouse. - - The mouse protocol is enabled when the <EM>mask</EM> passed in the - <STRONG>mousemask</STRONG> function is nonzero. By default, <EM>ncurses</EM> handles the - responses for the X11 xterm mouse protocol. It also knows about - the <EM>SGR</EM> <EM>1006</EM> xterm mouse protocol, but must to be told to look - for this specifically. It will not be able to guess which mode - is used, because the responses are enough alike that only - confusion would result. - - The <STRONG>XM</STRONG> capability has a single parameter. If nonzero, the mouse - protocol should be enabled. If zero, the mouse protocol should - be disabled. <EM>ncurses</EM> inspects this capability if it is present, - to see whether the 1006 protocol is used. If so, it expects the - responses to use the <EM>SGR</EM> <EM>1006</EM> xterm mouse protocol. - - The xterm mouse protocol is used by other terminal emulators. - The terminal database uses building-blocks for the various xterm - mouse protocols which can be used in customized terminal - descriptions. + by the terminal to tell the application what was done with the + mouse. + + The mouse protocol is enabled when the <EM>mask</EM> argument to the + <STRONG><A HREF="curs_mouse.3x.html">mousemask(3x)</A></STRONG> function is nonzero. By default, <EM>ncurses</EM> handles + the responses for the X11 <EM>xterm</EM> mouse protocol. It also knows + about the SGR 1006 <EM>xterm</EM> mouse protocol, but must to be told to + look for it specifically. <EM>ncurses</EM> is not be able to guess which + of the two modes is used, because the responses are enough alike + that only confusion would result. + + The <STRONG>XM</STRONG> capability has a single numeric parameter. If nonzero, + the mouse protocol should be enabled. If zero, the mouse + protocol should be disabled. <EM>ncurses</EM> inspects this capability if + it is present, to see whether the 1006 protocol is used. If so, + it expects the responses to use the SGR 1006 <EM>xterm</EM> mouse + protocol. + + The <EM>xterm</EM> mouse protocol is used by other terminal emulators. + The terminal database uses building blocks for the various <EM>xterm</EM> + mouse protocols usable in customized terminal descriptions. The terminal database building blocks for this mouse feature also - have an experimental capability <EM>xm</EM>. The "xm" capability - describes the mouse response. Currently there is no interpreter - which would use this information to make the mouse support - completely data-driven. + have an experimental capability, <STRONG>xm</STRONG>, that describes the mouse + response. No known interpreter uses this information, which + could make mouse support completely data-driven. - <EM>xm</EM> shows the format of the mouse responses. In this experimental - capability, the parameters are + <STRONG>xm</STRONG> shows the format of the mouse responses. In this experimental + capability, the parameters are as follows. <EM>p1</EM> y-ordinate @@ -296,8 +300,8 @@ <EM>p8</EM> x-ordinate ending region - Here are examples from the terminal database for the most - commonly used xterm mouse protocols: + Here are examples from the terminal database for the most + commonly used <EM>xterm</EM> mouse protocols. xterm+x11mouse|X11 xterm mouse protocol, kmous=\E[M, XM=\E[?1000%?%p1%{1}%=%th%el%;, @@ -315,20 +319,20 @@ </PRE><H3><a name="h3-Extended-Key-Definitions">Extended Key Definitions</a></H3><PRE> - Several terminals provide the ability to send distinct strings for - combinations of modified special keys. There is no standard for what + Several terminals provide the ability to send distinct strings for + combinations of modified special keys. There is no standard for what those keys can send. - Since 1999, <STRONG>xterm(1)</STRONG> has supported <EM>shift</EM>, <EM>control</EM>, <EM>alt</EM>, and <EM>meta</EM> - modifiers which produce distinct special-key strings. In a terminal - description, <EM>ncurses</EM> has no special knowledge of the modifiers used. - Applications can use the <EM>naming</EM> <EM>convention</EM> established for <STRONG>xterm</STRONG> to + Since 1999, <STRONG>xterm(1)</STRONG> has supported <EM>shift</EM>, <EM>control</EM>, <EM>alt</EM>, and <EM>meta</EM> + modifiers which produce distinct special-key strings. In a terminal + description, <EM>ncurses</EM> has no special knowledge of the modifiers used. + Applications can use the <EM>naming</EM> <EM>convention</EM> established for <EM>xterm</EM> to find these special keys in the terminal description. - Starting with the <EM>curses</EM> convention that capability codes describing - the input generated by a terminal's key caps begin with "k", and that - shifted special keys use uppercase letters in their names, <EM>ncurses</EM>'s - terminal database defines the following names and codes to which a + Starting with the <EM>curses</EM> convention that capability codes describing + the input generated by a terminal's key caps begin with "k", and that + shifted special keys use uppercase letters in their names, <EM>ncurses</EM>'s + terminal database defines the following names and codes to which a suffix is added. <STRONG>Code</STRONG> <STRONG>Description</STRONG> @@ -343,8 +347,8 @@ <STRONG>kRIT</STRONG> shifted kcuf1 (cursor forward) <STRONG>kUP</STRONG> shifted kcuu1 (cursor up) - Keycap nomenclature on the Unix systems for which <EM>curses</EM> was developed - differs from today's ubiquitous descendants of the IBM PC/AT keyboard + Keycap nomenclature on the Unix systems for which <EM>curses</EM> was developed + differs from today's ubiquitous descendants of the IBM PC/AT keyboard layout. In the foregoing, interpret "backward" as "left", "forward" as "right", "next" as "page down", and "prev(ious)" as "page up". @@ -368,20 +372,21 @@ 15 Meta + Ctrl + Alt 16 Meta + Ctrl + Alt + Shift - None of these are predefined; terminal descriptions can refer to <EM>names</EM> - which <EM>ncurses</EM> will allocate at runtime to <EM>key-codes</EM>. To use these keys - in an <EM>ncurses</EM> program, an application could do this: + <EM>ncurses</EM> defines no capabilities for modified F-keys; terminal + descriptions can refer to <EM>names</EM> that <EM>ncurses</EM> allocates at runtime to + <EM>key</EM> <EM>codes</EM>. To use these keys in an <EM>ncurses</EM> program, an application + could do this: - <STRONG>o</STRONG> using a list of extended key <EM>names</EM>, ask <STRONG><A HREF="curs_terminfo.3x.html">tigetstr(3x)</A></STRONG> for their + <STRONG>o</STRONG> using a list of extended key <EM>names</EM>, ask <STRONG><A HREF="curs_terminfo.3x.html">tigetstr(3x)</A></STRONG> for their values, and - <STRONG>o</STRONG> given the list of values, ask <STRONG><A HREF="key_defined.3x.html">key_defined(3x)</A></STRONG> for the <EM>key-code</EM> + <STRONG>o</STRONG> given the list of values, ask <STRONG><A HREF="key_defined.3x.html">key_defined(3x)</A></STRONG> for the <EM>key-code</EM> which would be returned for those keys by <STRONG><A HREF="curs_getch.3x.html">wgetch(3x)</A></STRONG>. </PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE> - The "-x" extension feature of <STRONG>tic</STRONG> and <STRONG>infocmp</STRONG> has been adopted in - NetBSD curses. That implementation stores user-defined capabilities, + The "-x" extension feature of <STRONG>tic</STRONG> and <STRONG>infocmp</STRONG> has been adopted in + NetBSD <EM>curses</EM>. That implementation stores user-defined capabilities, but makes no use of these capabilities itself. @@ -393,17 +398,15 @@ </PRE><H2><a name="h2-SEE-ALSO">SEE ALSO</a></H2><PRE> <STRONG><A HREF="infocmp.1m.html">infocmp(1m)</A></STRONG>, <STRONG><A HREF="tic.1m.html">tic(1m)</A></STRONG> - The terminal database section <EM>NCURSES</EM> <EM>USER-DEFINABLE</EM> <EM>CAPABILITIES</EM> - summarizes commonly-used user-defined capabilities which are used in - the terminal descriptions. Some of those features are mentioned in - <STRONG>screen(1)</STRONG> or <STRONG>tmux(1)</STRONG>. + In the source form of the terminal database, <EM>terminfo.src</EM>, the section + "NCURSES USER-DEFINABLE CAPABILITIES". summarizes commonly-used user- + defined capabilities employed in the terminal descriptions. Some of + those features are mentioned in <STRONG>screen(1)</STRONG> or <STRONG>tmux(1)</STRONG>. - <EM>XTerm</EM> <EM>Control</EM> <EM>Sequences</EM> provides further information on the <STRONG>xterm(1)</STRONG> + <EM>XTerm</EM> <EM>Control</EM> <EM>Sequences</EM> provides further information on the <STRONG>xterm(1)</STRONG> features that are used in these extended capabilities. - - -ncurses 6.5 2024-03-16 <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG> +ncurses 6.6 2025-11-11 <STRONG><A HREF="user_caps.5.html">user_caps(5)</A></STRONG> </PRE> <div class="nav"> <ul> |