[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 2/9] Protect literals from hyphenation.
|
From: |
G. Branden Robinson |
|
Subject: |
[PATCH 2/9] Protect literals from hyphenation. |
|
Date: |
Fri, 22 Sep 2023 12:58:16 -0500 |
Everything that is boldfaced is literal, so protect it from hyphenation.
A few very short words that *roff won't hyphenate (like "tic") are left
as-is.
GNU troff (by default) won't hyphenate "color", but will "colors".
* man/curs_color.3x:
* man/curs_getyx.3x:
* man/curs_inopts.3x:
* man/curs_legacy.3x:
* man/curs_memleaks.3x:
* man/curs_mouse.3x:
* man/curs_trace.3x: Do it.
---
man/curs_color.3x | 208 +++++++++++++++++++++----------------------
man/curs_getyx.3x | 46 +++++-----
man/curs_inopts.3x | 134 ++++++++++++++--------------
man/curs_legacy.3x | 42 ++++-----
man/curs_memleaks.3x | 38 ++++----
man/curs_mouse.3x | 90 +++++++++----------
man/curs_trace.3x | 60 ++++++-------
7 files changed, 309 insertions(+), 309 deletions(-)
diff --git a/man/curs_color.3x b/man/curs_color.3x
index 7357fa99..509ebc25 100644
--- a/man/curs_color.3x
+++ b/man/curs_color.3x
@@ -84,48 +84,48 @@ .SH SYNOPSIS
.SH DESCRIPTION
.SS Overview
\fBcurses\fP supports color attributes on terminals with that capability.
-To use these routines \fBstart_color\fP must be called, usually right after
-\fBinitscr\fP.
+To use these routines \fB\%start_color\fP must be called, usually right after
+\fB\%initscr\fP.
Colors are always used in pairs (referred to as color-pairs).
A color-pair consists of a foreground color (for characters) and a background
color (for the blank field on which the characters are displayed).
-A programmer initializes a color-pair with the routine \fBinit_pair\fP.
-After it has been initialized, \fBCOLOR_PAIR\fP(\fIn\fP)
+A programmer initializes a color-pair with the routine \fB\%init_pair\fP.
+After it has been initialized, \fB\%COLOR_PAIR\fP(\fIn\fP)
can be used to convert the pair to a video attribute.
.PP
If a terminal is capable of redefining colors, the programmer can use the
-routine \fBinit_color\fP to change the definition of a color.
-The routines \fBhas_colors\fP and \fBcan_change_color\fP
+routine \fB\%init_color\fP to change the definition of a color.
+The routines \fB\%has_colors\fP and \fB\%can_change_color\fP
return \fBTRUE\fP or \fBFALSE\fP,
depending on whether the terminal has color capabilities and whether the
programmer can change the colors.
-The routine \fBcolor_content\fP allows a
+The routine \fB\%color_content\fP allows a
programmer to extract the amounts of red, green, and blue components in an
initialized color.
-The routine \fBpair_content\fP allows a programmer to find
+The routine \fB\%pair_content\fP allows a programmer to find
out how a given color-pair is currently defined.
.SS Color Rendering
The \fBcurses\fP library combines these inputs to produce the
actual foreground and background colors shown on the screen:
.bP
-per-character video attributes (e.g., via \fBwaddch\fP),
+per-character video attributes (e.g., via \fB\%waddch\fP),
.bP
-the window attribute (e.g., by \fBwattrset\fP), and
+the window attribute (e.g., by \fB\%wattrset\fP), and
.bP
-the background character (e.g., \fBwbkgdset\fP).
+the background character (e.g., \fB\%wbkgdset\fP).
.PP
Per-character and window attributes are usually set by a parameter containing
video attributes including a color pair value.
-Some functions such as \fBwattr_set\fP use a separate parameter which
+Some functions such as \fB\%wattr_set\fP use a separate parameter which
is the color pair number.
.PP
The background character is a special case: it includes a character value,
-just as if it were passed to \fBwaddch\fP.
+just as if it were passed to \fB\%waddch\fP.
.PP
The \fBcurses\fP library does the actual work of combining these color
-pairs in an internal function called from \fBwaddch\fP:
+pairs in an internal function called from \fB\%waddch\fP:
.bP
-If the parameter passed to \fBwaddch\fP is \fIblank\fP,
+If the parameter passed to \fB\%waddch\fP is \fIblank\fP,
and it uses the special color pair 0,
.RS
.bP
@@ -137,21 +137,21 @@ .SS Color Rendering
Otherwise, \fBcurses\fP uses the background character.
.RE
.bP
-If the parameter passed to \fBwaddch\fP is \fInot blank\fP,
+If the parameter passed to \fB\%waddch\fP is \fInot blank\fP,
or it does not use the special color pair 0,
\fBcurses\fP prefers the color pair from the parameter,
if it is nonzero.
Otherwise, it tries the window attribute next, and finally the
background character.
.PP
-Some \fBcurses\fP functions such as \fBwprintw\fP call \fBwaddch\fP.
+Some \fBcurses\fP functions such as \fB\%wprintw\fP call \fB\%waddch\fP.
Those do not combine its parameter with a color pair.
Consequently those calls use only the window attribute or
the background character.
.SH CONSTANTS
-In \fB<curses.h>\fP the following macros are defined.
+In \fB\%<curses.h>\fP the following macros are defined.
These are the standard colors (ISO-6429).
-\fBcurses\fP also assumes that \fBCOLOR_BLACK\fP is the default
+\fBcurses\fP also assumes that \fB\%COLOR_BLACK\fP is the default
background color for all terminals.
.PP
.nf
@@ -169,38 +169,38 @@ .SH CONSTANTS
There are no standard names for those additional colors.
.SH VARIABLES
.SS COLORS
-is initialized by \fBstart_color\fP to the maximum number of colors
+is initialized by \fB\%start_color\fP to the maximum number of colors
the terminal can support.
.SS COLOR_PAIRS
-is initialized by \fBstart_color\fP to the maximum number of color pairs
+is initialized by \fB\%start_color\fP to the maximum number of color pairs
the terminal can support.
.SH FUNCTIONS
.SS start_color
-The \fBstart_color\fP routine requires no arguments.
+The \fB\%start_color\fP routine requires no arguments.
It must be called if the programmer wants to use colors, and before any other
color manipulation routine is called.
-It is good practice to call this routine right after \fBinitscr\fP.
-\fBstart_color\fP does this:
+It is good practice to call this routine right after \fB\%initscr\fP.
+\fB\%start_color\fP does this:
.bP
-It initializes two global variables, \fBCOLORS\fP and
-\fBCOLOR_PAIRS\fP (respectively defining the maximum number of colors
+It initializes two global variables, \fB\%COLORS\fP and
+\fB\%COLOR_PAIRS\fP (respectively defining the maximum number of colors
and color-pairs the terminal can support).
.bP
-It initializes the special color pair \fB0\fP to the default foreground
+It initializes the special color pair \fB\%0\fP to the default foreground
and background colors.
No other color pairs are initialized.
.bP
It restores the colors on the terminal to the values
they had when the terminal was just turned on.
.bP
-If the terminal supports the \fBinitc\fP (\fBinitialize_color\fP) capability,
-\fBstart_color\fP
+If the terminal supports the \fBinitc\fP (\fB\%initialize_color\fP) capability,
+\fB\%start_color\fP
initializes its internal table representing the
red, green, and blue components of the color palette.
.IP
The components depend on whether the terminal uses
CGA (aka \*(``ANSI\*('') or
-HLS (i.e., the \fBhls\fP (\fBhue_lightness_saturation\fP) capability is set).
+HLS (i.e., the \fBhls\fP (\fB\%hue_lightness_saturation\fP) capability is set).
The table is initialized first for eight basic colors
(black, red, green, yellow, blue, magenta, cyan, and white),
using weights that depend upon the CGA/HLS choice.
@@ -215,28 +215,28 @@ .SS start_color
SVr4 uses a similar scheme, but uses \fB1000\fP
for the components of the initial eight colors.
.IP
-\fBstart_color\fP does not attempt to set the terminal's color palette
+\fB\%start_color\fP does not attempt to set the terminal's color palette
to match its built-in table.
-An application may use \fBinit_color\fP to alter the internal table
+An application may use \fB\%init_color\fP to alter the internal table
along with the terminal's color.
.PP
These limits apply to color values and color pairs.
Values outside these limits are not legal, and may result in a runtime error:
.bP
-\fBCOLORS\fP corresponds to the terminal database's \fBmax_colors\fP
capability,
-(see \fBterminfo\fP(\*n)).
+\fBCOLORS\fP corresponds to the terminal database's \fB\%max_colors\fP
capability,
+(see \fB\%terminfo\fP(\*n)).
.bP
-color values are expected to be in the range \fB0\fP to \fBCOLORS\-1\fP,
-inclusive (including \fB0\fP and \fBCOLORS\-1\fP).
+color values are expected to be in the range \fB0\fP to \fB\%COLORS\-1\fP,
+inclusive (including \fB0\fP and \fB\%COLORS\-1\fP).
.bP
a special color value \fB\-1\fP is used in certain extended functions
-to denote the \fIdefault color\fP (see \fBuse_default_colors\fP(3X)).
+to denote the \fIdefault color\fP (see \fB\%use_default_colors\fP(3X)).
.bP
-\fBCOLOR_PAIRS\fP corresponds to
-the terminal database's \fBmax_pairs\fP capability,
-(see \fBterminfo\fP(\*n)).
+\fB\%COLOR_PAIRS\fP corresponds to
+the terminal database's \fB\%max_pairs\fP capability,
+(see \fB\%terminfo\fP(\*n)).
.bP
-legal color pair values are in the range \fB1\fP to \fBCOLOR_PAIRS\-1\fP,
+legal color pair values are in the range \fB1\fP to \fB\%COLOR_PAIRS\-1\fP,
inclusive.
.bP
color pair \fB0\fP is special; it denotes \*(``no color\*(''.
@@ -245,27 +245,27 @@ .SS start_color
but is actually whatever the terminal implements before color is initialized.
It cannot be modified by the application.
.SS has_colors
-The \fBhas_colors\fP routine requires no arguments.
+The \fB\%has_colors\fP routine requires no arguments.
It returns \fBTRUE\fP if
the terminal can manipulate colors; otherwise, it returns \fBFALSE\fP.
This routine facilitates writing terminal-independent programs.
For example, a programmer can use it to decide
whether to use color or some other video attribute.
.SS can_change_color
-The \fBcan_change_color\fP routine requires no arguments.
+The \fB\%can_change_color\fP routine requires no arguments.
It returns \fBTRUE\fP if the terminal supports colors
and can change their definitions;
other, it returns \fBFALSE\fP.
This routine facilitates writing terminal-independent programs.
.SS init_pair
-The \fBinit_pair\fP routine changes the definition of a color-pair.
+The \fB\%init_pair\fP routine changes the definition of a color-pair.
It takes three arguments:
the number of the color-pair to be changed, the foreground
color number, and the background color number.
For portable applications:
.bP
The first argument must be a legal color pair value.
-If default colors are used (see \fBuse_default_colors\fP(3X))
+If default colors are used (see \fB\%use_default_colors\fP(3X))
the upper limit is adjusted to allow for extra pairs which use
a default color in foreground and/or background.
.bP
@@ -276,42 +276,42 @@ .SS init_pair
are changed to the new definition.
.PP
As an extension, ncurses allows you to set color pair \fB0\fP via
-the \fBassume_default_colors\fP(3X) routine, or to specify the use of
+the \fB\%assume_default_colors\fP(3X) routine, or to specify the use of
default colors (color number \fB\-1\fP) if you first invoke the
-\fBuse_default_colors\fP(3X) routine.
+\fB\%use_default_colors\fP(3X) routine.
.SS init_extended_pair
-Because \fBinit_pair\fP uses signed \fBshort\fPs for its parameters,
+Because \fB\%init_pair\fP uses signed \fBshort\fPs for its parameters,
that limits color-pairs and color-values
to 32767 on modern hardware.
-The extension \fBinit_extended_pair\fP uses \fBint\fPs
+The extension \fB\%init_extended_pair\fP uses \fBint\fPs
for the color-pair and color-value,
allowing a larger number of colors to be supported.
.SS init_color
-The \fBinit_color\fP routine changes the definition of a color.
+The \fB\%init_color\fP routine changes the definition of a color.
It takes four arguments:
the number of the color to be changed followed by three RGB values
(for the amounts of red, green, and blue components).
.bP
The first argument must be a legal color value;
default colors are not allowed here.
-(See the section \fBColors\fP for the default color index.)
+(See the section \fB\%Colors\fP for the default color index.)
.bP
Each of the last three arguments
must be a value in the range \fB0\fP through \fB1000\fP.
.PP
-When \fBinit_color\fP is used, all
+When \fB\%init_color\fP is used, all
occurrences of that color on the screen immediately change to the new
definition.
.SS init_extended_color
-Because \fBinit_color\fP uses signed \fBshort\fPs for its parameters,
+Because \fB\%init_color\fP uses signed \fBshort\fPs for its parameters,
that limits color-values and their red, green, and blue components
to 32767 on modern hardware.
-The extension \fBinit_extended_color\fP uses \fBint\fPs
+The extension \fB\%init_extended_color\fP uses \fBint\fPs
for the color value and
for setting the red, green, and blue components,
allowing a larger number of colors to be supported.
.SS color_content
-The \fBcolor_content\fP routine gives programmers a way to find the intensity
+The \fB\%color_content\fP routine gives programmers a way to find the intensity
of the red, green, and blue (RGB) components in a color.
It requires four arguments: the color number, and three addresses
of \fBshort\fRs for storing
@@ -319,57 +319,57 @@ .SS color_content
given color.
.bP
The first argument must be a legal color value, i.e.,
-\fB0\fP through \fBCOLORS\-1\fP, inclusive.
+\fB0\fP through \fB\%COLORS\-1\fP, inclusive.
.bP
The values that are stored at the addresses pointed to by the
last three arguments are in the range
\fB0\fP (no component) through \fB1000\fP
(maximum amount of component), inclusive.
.SS extended_color_content
-Because \fBcolor_content\fP uses signed \fBshort\fPs for its parameters,
+Because \fB\%color_content\fP uses signed \fBshort\fPs for its parameters,
that limits color-values and their red, green, and blue components
to 32767 on modern hardware.
-The extension \fBextended_color_content\fP uses \fBint\fPs
+The extension \fB\%extended_color_content\fP uses \fBint\fPs
for the color value and
for returning the red, green, and blue components,
allowing a larger number of colors to be supported.
.SS pair_content
-The \fBpair_content\fP routine allows programmers to find out what colors a
+The \fB\%pair_content\fP routine allows programmers to find out what colors a
given color-pair consists of.
It requires three arguments: the color-pair
number, and two addresses of \fBshort\fRs for storing the foreground and the
background color numbers.
.bP
The first argument must be a legal color value,
-i.e., in the range \fB1\fP through \fBCOLOR_PAIRS\-1\fP, inclusive.
+i.e., in the range \fB1\fP through \fB\%COLOR_PAIRS\-1\fP, inclusive.
.bP
The values that are stored at the addresses pointed
to by the second and third arguments are in the
-range \fB0\fP through \fBCOLORS\fP, inclusive.
+range \fB0\fP through \fB\%COLORS\fP, inclusive.
.SS extended_pair_content
-Because \fBpair_content\fP uses signed \fBshort\fPs for its parameters,
+Because \fB\%pair_content\fP uses signed \fBshort\fPs for its parameters,
that limits color-pair and color-values to 32767 on modern hardware.
-The extension \fBextended_pair_content\fP uses \fBint\fPs
+The extension \fB\%extended_pair_content\fP uses \fBint\fPs
for the color pair and
for returning the foreground and background colors,
allowing a larger number of colors to be supported.
.SS reset_color_pairs
-The extension \fBreset_color_pairs\fP tells ncurses to discard all
-of the color-pair information which was set with \fBinit_pair\fP.
+The extension \fB\%reset_color_pairs\fP tells ncurses to discard all
+of the color-pair information which was set with \fB\%init_pair\fP.
It also touches the current- and standard-screens, allowing an application to
switch color palettes rapidly.
.SS PAIR_NUMBER
-\fBPAIR_NUMBER(\fIattrs\fR) extracts the color
+\fB\%PAIR_NUMBER(\fIattrs\fR) extracts the color
value from its \fIattrs\fP parameter and returns it as a color pair number.
.SS COLOR_PAIR
-Its inverse \fBCOLOR_PAIR(\fIn\fB)\fR converts a color pair number
+Its inverse \fB\%COLOR_PAIR(\fIn\fB)\fR converts a color pair number
to an attribute.
Attributes can hold color pairs in the range 0 to 255.
If you need a color pair larger than that, you must use functions
-such as \fBattr_set\fP (which pass the color pair as a separate parameter)
-rather than the legacy functions such as \fBattrset\fP.
+such as \fB\%attr_set\fP (which pass the color pair as a separate parameter)
+rather than the legacy functions such as \fB\%attrset\fP.
.SH RETURN VALUE
-The routines \fBcan_change_color\fP and \fBhas_colors\fP return \fBTRUE\fP
+The routines \fB\%can_change_color\fP and \fB\%has_colors\fP return \fBTRUE\fP
or \fBFALSE\fP.
.PP
All other routines return the integer \fBERR\fP upon failure and an \fBOK\fP
@@ -380,24 +380,24 @@ .SH RETURN VALUE
SVr4 does document some error conditions which apply in general:
.bP
This implementation will return \fBERR\fP on attempts to
-use color values outside the range \fB0\fP to \fBCOLORS\fP\-1
+use color values outside the range \fB0\fP to \fB\%COLORS\fP\-1
(except for the default colors extension),
-or use color pairs outside the range \fB0\fP to \fBCOLOR_PAIRS\-1\fP.
+or use color pairs outside the range \fB0\fP to \fB\%COLOR_PAIRS\-1\fP.
.IP
-Color values used in \fBinit_color\fP must be
+Color values used in \fB\%init_color\fP must be
in the range \fB0\fP to \fB1000\fP.
.IP
An error is returned from all functions
if the terminal has not been initialized.
.IP
-An error is returned from secondary functions such as \fBinit_pair\fP
-if \fBstart_color\fP was not called.
+An error is returned from secondary functions such as \fB\%init_pair\fP
+if \fB\%start_color\fP was not called.
.bP
SVr4 does much the same, except that
-it returns \fBERR\fP from \fBpair_content\fP if the pair was not initialized
-using \fBinit_pairs\fP
+it returns \fBERR\fP from \fB\%pair_content\fP if the pair was not initialized
+using \fB\%init_pairs\fP
and
-it returns \fBERR\fP from \fBcolor_content\fP
+it returns \fBERR\fP from \fB\%color_content\fP
if the terminal does not support changing colors.
.IP
This implementation does not return \fBERR\fP for either case.
@@ -405,19 +405,19 @@ .SH RETURN VALUE
Specific functions make additional checks:
.RS 3
.TP 5
-\fBinit_color\fP
+\fB\%init_color\fP
returns an error if the terminal does not support
-this feature, e.g., if the \fBinitialize_color\fP capability is absent
+this feature, e.g., if the \fB\%initialize_color\fP capability is absent
from the terminal description.
.TP 5
-\fBstart_color\fP
+\fB\%start_color\fP
returns an error if the color table cannot be allocated.
.RE
.SH NOTES
In the \fBncurses\fP implementation, there is a separate color activation flag,
color palette, color pairs table,
-and associated \fBCOLORS\fP and \fBCOLOR_PAIRS\fP counts
-for each screen; the \fBstart_color\fP function only affects the current
+and associated \fB\%COLORS\fP and \fB\%COLOR_PAIRS\fP counts
+for each screen; the \fB\%start_color\fP function only affects the current
screen.
The SVr4/XSI interface is not really designed with this in mind, and
historical implementations may use a single shared color palette.
@@ -426,7 +426,7 @@ .SH NOTES
character cells that a character write operation explicitly touches.
To change
the background color used when parts of a window are blanked by erasing or
-scrolling operations, see \fBcurs_bkgd\fP(3X).
+scrolling operations, see \fB\%curs_bkgd\fP(3X).
.PP
Several caveats apply on older x86 machines
(e.g., i386, i486) with VGA-compatible graphics:
@@ -447,13 +447,13 @@ .SH HISTORY
SVr4 made internal changes,
e.g., moving the storage for the color state
from \fBSP\fP (the \fBSCREEN\fP structure)
-to \fBcur_term\fP (the \fBTERMINAL\fP structure),
+to \fB\%cur_term\fP (the \fB\%TERMINAL\fP structure),
but provided the same set of library functions.
.PP
SVr4 curses limits the number of color pairs to 64,
reserving color pair zero (0) as the terminal's initial uncolored state.
This limit arises because the color pair information is a bitfield
-in the \fBchtype\fP data type (denoted by \fBA_COLOR\fP).
+in the \fB\%chtype\fP data type (denoted by \fB\%A_COLOR\fP).
.PP
Other implementations of curses had different limits:
.bP
@@ -461,24 +461,24 @@ .SH HISTORY
.bP
PDCurses (1992-present) inherited the 8-color limitation from PCCurses,
but changed this to 256 in version 2.5 (2001),
-along with changing \fBchtype\fP from 16-bits to 32-bits.
+along with changing \fB\%chtype\fP from 16-bits to 32-bits.
.bP
X/Open Curses (1992-present)
-added a new structure \fBcchar_t\fP to store the character,
+added a new structure \fB\%cchar_t\fP to store the character,
attributes and color-pair values, allowing increased range of color-pairs.
Both color-pairs and color-values used a signed \fBshort\fP,
limiting values to 15 bits.
.bP
-ncurses (1992-present) uses eight bits for \fBA_COLOR\fP in \fBchtype\fP
values.
+ncurses (1992-present) uses eight bits for \fB\%A_COLOR\fP in \fB\%chtype\fP
values.
.IP
Version 5.3 provided a wide-character interface (2002),
but left color-pairs as part of the attributes-field.
.IP
Since version 6 (2015),
-ncurses uses a separate \fBint\fP for color-pairs in the \fBcchar_t\fP values.
+ncurses uses a separate \fBint\fP for color-pairs in the \fB\%cchar_t\fP
values.
When those color-pair values fit in 8 bits,
ncurses allows color-pairs to be manipulated
-via the functions using \fBchtype\fP values.
+via the functions using \fB\%chtype\fP values.
.bP
NetBSD curses used 6 bits from
2000 (when colors were first supported) until 2004.
@@ -486,7 +486,7 @@ .SH HISTORY
As of 2021, that size is unchanged.
Like ncurses before version 6,
the NetBSD color-pair information is stored in
-the attributes field of \fBcchar_t\fP, limiting the number of color-pairs
+the attributes field of \fB\%cchar_t\fP, limiting the number of color-pairs
by the size of the bitfield.
.SH PORTABILITY
.SS Extensions
@@ -495,19 +495,19 @@ .SS Extensions
or any other previous version of curses.
.SS Standards
This implementation satisfies XSI Curses's minimum maximums
-for \fBCOLORS\fP and \fBCOLOR_PAIRS\fP.
+for \fB\%COLORS\fP and \fB\%COLOR_PAIRS\fP.
.PP
-The \fBinit_pair\fP routine accepts negative values of foreground
-and background color to support the \fBuse_default_colors\fP(3X) extension,
+The \fB\%init_pair\fP routine accepts negative values of foreground
+and background color to support the \fB\%use_default_colors\fP(3X) extension,
but only if that routine has been first invoked.
.PP
-The assumption that \fBCOLOR_BLACK\fP is the default
+The assumption that \fB\%COLOR_BLACK\fP is the default
background color for all terminals can be modified using the
-\fBassume_default_colors\fP(3X) extension.
+\fB\%assume_default_colors\fP(3X) extension.
.PP
This implementation checks the pointers,
e.g., for the values returned by
-\fBcolor_content\fP and \fBpair_content\fP,
+\fB\%color_content\fP and \fB\%pair_content\fP,
and will treat those as optional parameters when null.
.PP
X/Open Curses does not specify a limit for the number of colors and
@@ -519,10 +519,10 @@ .SS Standards
which use \fBshort\fP parameters,
allowing applications to use larger color- and pair-numbers.
.PP
-The \fBreset_color_pairs\fP function is an extension of ncurses.
+The \fB\%reset_color_pairs\fP function is an extension of ncurses.
.SH SEE ALSO
-\fBcurses\fP(3X),
-\fBcurs_initscr\fP(3X),
-\fBcurs_attr\fP(3X),
-\fBcurs_variables\fP(3X),
-\fBdefault_colors\fP(3X)
+\fB\%curses\fP(3X),
+\fB\%curs_initscr\fP(3X),
+\fB\%curs_attr\fP(3X),
+\fB\%curs_variables\fP(3X),
+\fB\%default_colors\fP(3X)
diff --git a/man/curs_getyx.3x b/man/curs_getyx.3x
index ebed93b9..5e07be7d 100644
--- a/man/curs_getyx.3x
+++ b/man/curs_getyx.3x
@@ -45,15 +45,15 @@ .SH SYNOPSIS
\fBvoid getmaxyx(WINDOW *\fIwin\fB, int \fIy\fB, int \fIx\fB);\fR
.fi
.SH DESCRIPTION
-The \fBgetyx\fP macro places the current cursor position of the given window in
+The \fB\%getyx\fP macro places the current cursor position of the given window
in
the two integer variables \fIy\fP and \fIx\fP.
.PP
-If \fIwin\fP is a subwindow, the \fBgetparyx\fP macro places the beginning
+If \fIwin\fP is a subwindow, the \fB\%getparyx\fP macro places the beginning
coordinates of the subwindow relative to the parent window into two integer
variables \fIy\fP and \fIx\fP.
Otherwise, \fB\-1\fP is placed into \fIy\fP and \fIx\fP.
.PP
-Like \fBgetyx\fP, the \fBgetbegyx\fP and \fBgetmaxyx\fP macros store
+Like \fB\%getyx\fP, the \fB\%getbegyx\fP and \fB\%getmaxyx\fP macros store
the current beginning coordinates and size of the specified window.
.SH RETURN VALUE
The return values of these macros are undefined (i.e.,
@@ -63,38 +63,38 @@ .SH NOTES
A "\fB&\fP" is not necessary before the variables \fIy\fP and \fIx\fP.
.SH PORTABILITY
The
-\fBgetyx\fP,
-\fBgetparyx\fP,
-\fBgetbegyx\fP and
-\fBgetmaxyx\fP
+\fB\%getyx\fP,
+\fB\%getparyx\fP,
+\fB\%getbegyx\fP and
+\fB\%getmaxyx\fP
macros are described in the XSI Curses standard, Issue 4.
.PP
This implementation also provides functions
-\fBgetbegx\fP,
-\fBgetbegy\fP,
-\fBgetcurx\fP,
-\fBgetcury\fP,
-\fBgetmaxx\fP,
-\fBgetmaxy\fP,
-\fBgetparx\fP and
-\fBgetpary\fP
+\fB\%getbegx\fP,
+\fB\%getbegy\fP,
+\fB\%getcurx\fP,
+\fB\%getcury\fP,
+\fB\%getmaxx\fP,
+\fB\%getmaxy\fP,
+\fB\%getparx\fP and
+\fB\%getpary\fP
for compatibility with older versions of curses.
.PP
Although X/Open Curses does not address this,
-many implementations provide members of the WINDOW structure
+many implementations provide members of the \%WINDOW structure
containing values corresponding to these macros.
-For best portability, do not rely on using the data in WINDOW,
-since some implementations make WINDOW opaque (do not allow
+For best portability, do not rely on using the data in \%WINDOW,
+since some implementations make \%WINDOW opaque (do not allow
direct use of its members).
.PP
Besides the problem of opaque structures,
the data stored in like-named members may not have like-values in
different implementations.
-For example, the WINDOW._maxx and WINDOW._maxy values in ncurses
+For example, the \%WINDOW._maxx and \%WINDOW._maxy values in ncurses
have (at least since release 1.8.1) differed by one from some
other implementations.
-The difference is hidden by means of the macro \fBgetmaxyx\fP.
+The difference is hidden by means of the macro \fB\%getmaxyx\fP.
.SH SEE ALSO
-\fBcurses\fP(3X),
-\fBcurs_legacy\fP(3X),
-\fBcurs_opaque\fP(3X)
+\fB\%curses\fP(3X),
+\fB\%curs_legacy\fP(3X),
+\fB\%curs_opaque\fP(3X)
diff --git a/man/curs_inopts.3x b/man/curs_inopts.3x
index b96c8103..e7859e7b 100644
--- a/man/curs_inopts.3x
+++ b/man/curs_inopts.3x
@@ -109,48 +109,48 @@ .SH DESCRIPTION
.SS cbreak/nocbreak
Normally, the tty driver buffers typed characters until a newline or carriage
return is typed.
-The \fBcbreak\fP routine disables line buffering and
+The \fB\%cbreak\fP routine disables line buffering and
erase/kill character-processing (interrupt and flow control characters are
unaffected), making characters typed by the user immediately available to the
program.
-The \fBnocbreak\fP routine returns the terminal to normal (cooked)
+The \fB\%nocbreak\fP routine returns the terminal to normal (cooked)
mode.
.PP
-Initially the terminal may or may not be in \fBcbreak\fP mode, as the mode is
-inherited; therefore, a program should call \fBcbreak\fP or \fBnocbreak\fP
+Initially the terminal may or may not be in \fB\%cbreak\fP mode, as the mode is
+inherited; therefore, a program should call \fB\%cbreak\fP or \fB\%nocbreak\fP
explicitly.
-Most interactive programs using \fBcurses\fP set the \fBcbreak\fP
+Most interactive programs using \fBcurses\fP set the \fB\%cbreak\fP
mode.
-Note that \fBcbreak\fP overrides \fBraw\fP.
-[See \fBcurs_getch\fP(3X) for a
-discussion of how these routines interact with \fBecho\fP and \fBnoecho\fP.]
+Note that \fB\%cbreak\fP overrides \fBraw\fP.
+[See \fB\%curs_getch\fP(3X) for a
+discussion of how these routines interact with \fBecho\fP and \fB\%noecho\fP.]
.\"
.SS echo/noecho
-The \fBecho\fP and \fBnoecho\fP routines control whether characters typed by
-the user are echoed by \fBgetch\fP(3X) as they are typed.
+The \fBecho\fP and \fB\%noecho\fP routines control whether characters typed by
+the user are echoed by \fB\%getch\fP(3X) as they are typed.
Echoing by the tty
-driver is always disabled, but initially \fBgetch\fP is in echo mode, so
+driver is always disabled, but initially \fB\%getch\fP is in echo mode, so
characters typed are echoed.
Authors of most interactive programs prefer to do
their own echoing in a controlled area of the screen, or not to echo at all, so
-they disable echoing by calling \fBnoecho\fP.
-[See \fBcurs_getch\fP(3X) for a
-discussion of how these routines interact with \fBcbreak\fP and
-\fBnocbreak\fP.]
+they disable echoing by calling \fB\%noecho\fP.
+[See \fB\%curs_getch\fP(3X) for a
+discussion of how these routines interact with \fB\%cbreak\fP and
+\fB\%nocbreak\fP.]
.\"
.SS halfdelay
-The \fBhalfdelay\fP routine is used for half-delay mode, which is similar to
-\fBcbreak\fP mode in that characters typed by the user are immediately
+The \fB\%halfdelay\fP routine is used for half-delay mode, which is similar to
+\fB\%cbreak\fP mode in that characters typed by the user are immediately
available to the program.
However, after blocking for \fItenths\fP tenths of
seconds, \fBERR\fP is returned if nothing has been typed.
The value of \fItenths\fP
must be a number between 1 and 255.
-Use \fBnocbreak\fP to leave half-delay
+Use \fB\%nocbreak\fP to leave half-delay
mode.
.\"
.SS intrflush
-If the \fBintrflush\fP option is enabled (\fIbf\fP is \fBTRUE\fP), and an
+If the \fB\%intrflush\fP option is enabled (\fIbf\fP is \fBTRUE\fP), and an
interrupt key is pressed on the keyboard (interrupt, break, quit), all output
in
the tty driver queue will be flushed, giving the effect of faster response to
the interrupt, but causing \fBcurses\fP to have the wrong idea of what is on
@@ -161,24 +161,24 @@ .SS intrflush
The window argument is ignored.
.\"
.SS keypad
-The \fBkeypad\fP option enables the keypad of the user's terminal.
+The \fB\%keypad\fP option enables the keypad of the user's terminal.
If
enabled (\fIbf\fP is \fBTRUE\fP), the user can press a function key
-(such as an arrow key) and \fBwgetch\fP(3X) returns a single value
-representing the function key, as in \fBKEY_LEFT\fP.
+(such as an arrow key) and \fB\%wgetch\fP(3X) returns a single value
+representing the function key, as in \fB\%KEY_LEFT\fP.
If disabled
(\fIbf\fP is \fBFALSE\fP), \fBcurses\fP does not treat function keys
specially and the program has to interpret the escape sequences
itself.
If the keypad in the terminal can be turned on (made to
transmit) and off (made to work locally), turning on this option
-causes the terminal keypad to be turned on when \fBwgetch\fP(3X) is
+causes the terminal keypad to be turned on when \fB\%wgetch\fP(3X) is
called.
The default value for keypad is \fBFALSE\fP.
.\"
.SS meta
Initially, whether the terminal returns 7 or 8 significant bits on
-input depends on the control mode of the tty driver [see \fBtermios\fP(3)].
+input depends on the control mode of the tty driver [see \fB\%termios\fP(3)].
To force 8 bits to be returned, invoke \fBmeta\fP(\fIwin\fP,
\fBTRUE\fP); this is equivalent, under POSIX, to setting the CS8 flag
on the terminal.
@@ -198,23 +198,23 @@ .SS nl/nonl
device translates the return key into newline on input.
.\"
.SS nodelay
-The \fBnodelay\fP option causes \fBgetch\fP to be a non-blocking call.
-If no input is ready, \fBgetch\fP returns \fBERR\fP.
+The \fB\%nodelay\fP option causes \fB\%getch\fP to be a non-blocking call.
+If no input is ready, \fB\%getch\fP returns \fBERR\fP.
If disabled
-(\fIbf\fP is \fBFALSE\fP), \fBgetch\fP waits until a key is pressed.
+(\fIbf\fP is \fBFALSE\fP), \fB\%getch\fP waits until a key is pressed.
.SS notimeout
-When interpreting an escape sequence, \fBwgetch\fP(3X) sets a timer
+When interpreting an escape sequence, \fB\%wgetch\fP(3X) sets a timer
while waiting for the next character.
-If \fBnotimeout(\fIwin\fR,
-\fBTRUE\fP) is called, then \fBwgetch\fP does not set a timer.
+If \fB\%notimeout(\fIwin\fR,
+\fBTRUE\fP) is called, then \fB\%wgetch\fP does not set a timer.
The
purpose of the timeout is to differentiate between sequences received
from a function key and those typed by a user.
.\"
.SS raw/noraw
-The \fBraw\fP and \fBnoraw\fP routines place the terminal into or out of raw
+The \fBraw\fP and \fB\%noraw\fP routines place the terminal into or out of raw
mode.
-Raw mode is similar to \fBcbreak\fP mode, in that characters typed are
+Raw mode is similar to \fB\%cbreak\fP mode, in that characters typed are
immediately passed through to the user program.
The differences are that in
raw mode, the interrupt, quit, suspend, and flow control characters are all
@@ -224,18 +224,18 @@ .SS raw/noraw
\fBcurses\fP.
.\"
.SS qiflush/noqiflush
-When the \fBnoqiflush\fP routine is used, normal flush of input and
+When the \fB\%noqiflush\fP routine is used, normal flush of input and
output queues associated with the \fBINTR\fP, \fBQUIT\fP and
-\fBSUSP\fP characters will not be done [see \fBtermios\fP(3)].
+\fBSUSP\fP characters will not be done [see \fB\%termios\fP(3)].
When
-\fBqiflush\fP is called, the queues will be flushed when these control
+\fB\%qiflush\fP is called, the queues will be flushed when these control
characters are read.
-You may want to call \fBnoqiflush\fP in a signal
+You may want to call \fB\%noqiflush\fP in a signal
handler if you want output to continue as though the interrupt
had not occurred, after the handler exits.
.\"
.SS timeout/wtimeout
-The \fBtimeout\fP and \fBwtimeout\fP routines set blocking or
+The \fB\%timeout\fP and \fB\%wtimeout\fP routines set blocking or
non-blocking read for a given window.
If \fIdelay\fP is negative,
blocking read is used (i.e., waits indefinitely for
@@ -245,7 +245,7 @@ .SS timeout/wtimeout
If
\fIdelay\fP is positive, then read blocks for \fIdelay\fP
milliseconds, and returns \fBERR\fP if there is still no input.
-Hence, these routines provide the same functionality as \fBnodelay\fP,
+Hence, these routines provide the same functionality as \fB\%nodelay\fP,
plus the additional capability of being able to block for only
\fIdelay\fP milliseconds (where \fIdelay\fP is positive).
.\"
@@ -254,12 +254,12 @@ .SS typeahead
by looking for typeahead periodically while updating the screen.
If input is found, and it is coming from a tty,
the current update is postponed until
-\fBrefresh\fP(3X) or \fBdoupdate\fP is called again.
+\fB\%refresh\fP(3X) or \fB\%doupdate\fP is called again.
This allows faster response to commands typed in advance.
Normally, the input FILE
-pointer passed to \fBnewterm\fP, or \fBstdin\fP in the case that
-\fBinitscr\fP was used, will be used to do this typeahead checking.
-The \fBtypeahead\fP routine specifies that the file descriptor
+pointer passed to \fB\%newterm\fP, or \fBstdin\fP in the case that
+\fB\%initscr\fP was used, will be used to do this typeahead checking.
+The \fB\%typeahead\fP routine specifies that the file descriptor
\fIfd\fP is to be used to check for typeahead instead.
If \fIfd\fP is
\-1, then no typeahead checking is done.
@@ -277,7 +277,7 @@ .SH RETURN VALUE
Also,
.RS 3
.TP 5
-\fBhalfdelay\fP
+\fB\%halfdelay\fP
returns an error
if its parameter is outside the range 1..255.
.RE
@@ -320,7 +320,7 @@ .SH PORTABILITY
BSD curses differed from this slightly; it
left the echo bit on at initialization, but the BSD \fBraw\fP call turned it
off as a side-effect.
-For best portability, set \fBecho \fPor \fBnoecho\fP explicitly
+For best portability, set \fBecho \fPor \fB\%noecho\fP explicitly
just after initialization, even if your program remains in cooked mode.
.PP
The XSI Curses standard is ambiguous on the question of whether \fBraw\fP
@@ -331,7 +331,7 @@ .SH PORTABILITY
raw input wants a clean (ideally 8-bit clean) connection that the operating
system will not alter.
.PP
-When \fBkeypad\fP is first enabled,
+When \fB\%keypad\fP is first enabled,
ncurses loads the key-definitions for the current terminal description.
If the terminal description includes extended string capabilities,
e.g., from using the \fB\-x\fP option of \fB@TIC@\fP,
@@ -340,22 +340,22 @@ .SH PORTABILITY
The corresponding keycodes are generated and (depending on previous
loads of terminal descriptions) may differ from one execution of a
program to the next.
-The generated keycodes are recognized by the \fBkeyname\fP function
+The generated keycodes are recognized by the \fB\%keyname\fP function
(which will then return a name beginning with \*(``k\*('' denoting the
terminfo capability name rather than \*(``K\*('', used for curses key-names).
-On the other hand, an application can use \fBdefine_key\fP to establish
+On the other hand, an application can use \fB\%define_key\fP to establish
a specific keycode for a given string.
This makes it possible for an application to check for an extended
-capability's presence with \fBtigetstr\fP,
+capability's presence with \fB\%tigetstr\fP,
and reassign the keycode to match its own needs.
.PP
-Low-level applications can use \fBtigetstr\fP to obtain the definition
+Low-level applications can use \fB\%tigetstr\fP to obtain the definition
of any particular string capability.
-Higher-level applications which use the curses \fBwgetch\fP
+Higher-level applications which use the curses \fB\%wgetch\fP
and similar functions to return keycodes rely upon the order in which
the strings are loaded.
If more than one key definition has the same string value,
-then \fBwgetch\fP can return only one keycode.
+then \fB\%wgetch\fP can return only one keycode.
Most curses implementations (including ncurses)
load key definitions in the order
defined by the array of string capability names.
@@ -369,28 +369,28 @@ .SH PORTABILITY
.SH NOTES
Note that
\fBecho\fP,
-\fBnoecho\fP,
-\fBhalfdelay\fP,
-\fBintrflush\fP,
+\fB\%noecho\fP,
+\fB\%halfdelay\fP,
+\fB\%intrflush\fP,
\fBmeta\fP,
\fBnl\fP,
\fBnonl\fP,
-\fBnodelay\fP,
-\fBnotimeout\fP,
-\fBnoqiflush\fP,
-\fBqiflush\fP,
-\fBtimeout\fP, and
-\fBwtimeout\fP may be macros.
+\fB\%nodelay\fP,
+\fB\%notimeout\fP,
+\fB\%noqiflush\fP,
+\fB\%qiflush\fP,
+\fB\%timeout\fP, and
+\fB\%wtimeout\fP may be macros.
.PP
-The \fBnoraw\fP and \fBnocbreak\fP calls follow historical practice in that
+The \fB\%noraw\fP and \fB\%nocbreak\fP calls follow historical practice in that
they attempt to restore to normal (\*(``cooked\*('') mode
from raw and cbreak modes respectively.
Mixing raw/noraw and cbreak/nocbreak calls leads to tty driver
control states that are hard to predict or understand; it is not recommended.
.SH SEE ALSO
-\fBcurses\fP(3X),
-\fBcurs_getch\fP(3X),
-\fBcurs_initscr\fP(3X),
-\fBcurs_util\fP(3X),
-\fBdefine_key\fP(3X),
-\fBtermios\fP(3)
+\fB\%curses\fP(3X),
+\fB\%curs_getch\fP(3X),
+\fB\%curs_initscr\fP(3X),
+\fB\%curs_util\fP(3X),
+\fB\%define_key\fP(3X),
+\fB\%termios\fP(3)
diff --git a/man/curs_legacy.3x b/man/curs_legacy.3x
index b36c9bb6..103dd562 100644
--- a/man/curs_legacy.3x
+++ b/man/curs_legacy.3x
@@ -65,30 +65,30 @@ .SH SYNOPSIS
.SH DESCRIPTION
These legacy functions are simpler to use than the X/Open Curses functions:
.bP
-The \fBgetattrs\fP function returns the same attribute data as \fBwattr_get\fP.
+The \fB\%getattrs\fP function returns the same attribute data as
\fB\%wattr_get\fP.
.IP
-However, \fBgetattrs\fP returns an integer (actually a \fBchtype\fP),
-while \fBwattr_get\fP returns the current color pair in a separate parameter.
+However, \fB\%getattrs\fP returns an integer (actually a \fB\%chtype\fP),
+while \fB\%wattr_get\fP returns the current color pair in a separate parameter.
In the wide-character library configuration,
-color pairs may not fit into a \fBchtype\fP,
-so \fBwattr_get\fP is the only way to obtain the color information.
+color pairs may not fit into a \fB\%chtype\fP,
+so \fB\%wattr_get\fP is the only way to obtain the color information.
.IP
-Because \fBgetattrs\fP returns the attributes in a single parameter,
+Because \fB\%getattrs\fP returns the attributes in a single parameter,
it would not be possible for an application to distinguish that from
\fBERR\fP (a \fI-1\fP).
-If the window parameter is null, \fBgetattrs\fP returns \fBA_NORMAL\fP (zero).
+If the window parameter is null, \fB\%getattrs\fP returns \fB\%A_NORMAL\fP
(zero).
.bP
-The \fBgetbegy\fP and \fBgetbegx\fP functions return the same
-data as \fBgetbegyx\fP.
+The \fB\%getbegy\fP and \fB\%getbegx\fP functions return the same
+data as \fB\%getbegyx\fP.
.bP
-The \fBgetcury\fP and \fBgetcurx\fP functions return the same
-data as \fBgetyx\fP.
+The \fB\%getcury\fP and \fB\%getcurx\fP functions return the same
+data as \fB\%getyx\fP.
.bP
-The \fBgetmaxy\fP and \fBgetmaxx\fP functions return the same
-data as \fBgetmaxyx\fP.
+The \fB\%getmaxy\fP and \fB\%getmaxx\fP functions return the same
+data as \fB\%getmaxyx\fP.
.bP
-The \fBgetpary\fP and \fBgetparx\fP functions return the same
-data as \fBgetparyx\fP.
+The \fB\%getpary\fP and \fB\%getparx\fP functions return the same
+data as \fB\%getparyx\fP.
.SH RETURN VALUE
Except as noted,
these functions return an integer,
@@ -96,8 +96,8 @@ .SH RETURN VALUE
.SH NOTES
All of these interfaces are provided as macros and functions.
The macros are suppressed (and only the functions provided)
-when \fBNCURSES_OPAQUE\fP is defined.
-The standard forms such as \fBgetyx\fP must be implemented as macros,
+when \fB\%NCURSES_OPAQUE\fP is defined.
+The standard forms such as \fB\%getyx\fP must be implemented as macros,
and (in this implementation) are defined in terms of the functions
described here,
to avoid reliance on internal details of the WINDOW structure.
@@ -105,10 +105,10 @@ .SH PORTABILITY
These functions were supported on Version 7, BSD or System V implementations.
None of those implementations checked the window parameter.
.PP
-The \fBgetattrs\fP function and macro are defined to return a (signed) integer
+The \fB\%getattrs\fP function and macro are defined to return a (signed)
integer
for compatibility with those implementations
although an unsigned type would have been more appropriate.
.SH SEE ALSO
-\fBcurses\fP(3X),
-\fBcurs_getyx\fP(3X),
-\fBcurs_opaque\fP(3X)
+\fB\%curses\fP(3X),
+\fB\%curs_getyx\fP(3X),
+\fB\%curs_opaque\fP(3X)
diff --git a/man/curs_memleaks.3x b/man/curs_memleaks.3x
index 5dd0f5c2..4b50590f 100644
--- a/man/curs_memleaks.3x
+++ b/man/curs_memleaks.3x
@@ -59,8 +59,8 @@ .SH DESCRIPTION
library.
.PP
Any implementation of curses must not free the memory associated with
-a screen, since (even after calling \fBendwin\fP(3X)), it must be available
-for use in the next call to \fBrefresh\fP(3X).
+a screen, since (even after calling \fB\%endwin\fP(3X)), it must be available
+for use in the next call to \fB\%refresh\fP(3X).
There are also chunks of memory held for performance reasons.
That makes it hard to analyze curses applications for memory leaks.
When using the specially configured debugging version of the ncurses library,
@@ -70,28 +70,28 @@ .SH DESCRIPTION
Some of the functions are named with a \*(``_nc_\*('' prefix
because they are not intended for use in the non-debugging library:
.TP 5
-\fB_nc_freeall\fP
+\fB\%_nc_freeall\fP
This frees (almost) all of the memory allocated by ncurses.
.TP 5
-\fB_nc_free_and_exit\fP
-This frees the memory allocated by ncurses (like \fB_nc_freeall\fP),
+\fB\%_nc_free_and_exit\fP
+This frees the memory allocated by ncurses (like \fB\%_nc_freeall\fP),
and exits the program.
-It is preferred over \fB_nc_freeall\fP since some of that memory
+It is preferred over \fB\%_nc_freeall\fP since some of that memory
may be required to keep the application running.
Simply exiting (with the given exit-code) is safer.
.TP 5
-\fB_nc_free_tinfo\fP
+\fB\%_nc_free_tinfo\fP
Use this function if only the low-level terminfo functions (and
corresponding library) are used.
-Like \fB_nc_free_and_exit\fP, it exits the program after freeing memory.
+Like \fB\%_nc_free_and_exit\fP, it exits the program after freeing memory.
.PP
The functions prefixed \*(``_nc\*('' are normally not available;
they must be configured into the library
-at build time using the \fB\-\-disable-leaks\fP option.
+at build time using the \fB\%\-\-disable-leaks\fP option.
That compiles-in code that frees memory that normally would not be freed.
.PP
-The \fBexit_curses\fP and \fBexit_terminfo\fP functions
-call \fB_nc_free_and_exit\fP and \fB_nc_free_tinfo\fP if
+The \fB\%exit_curses\fP and \fB\%exit_terminfo\fP functions
+call \fB\%_nc_free_and_exit\fP and \fB\%_nc_free_tinfo\fP if
the library is configured to support memory-leak checking.
If the library is not configured to support memory-leak checking,
they simply call \fBexit\fP.
@@ -104,18 +104,18 @@ .SH PORTABILITY
In any implementation of X/Open Curses, an application can free part
of the memory allocated by curses:
.bP
-The portable part of \fBexit_curses\fP can be freed using \fBdelscreen\fP,
-passing the \fBSCREEN*\fP pointer returned by \fBnewterm\fP.
+The portable part of \fB\%exit_curses\fP can be freed using \fB\%delscreen\fP,
+passing the \fBSCREEN*\fP pointer returned by \fB\%newterm\fP.
.IP
In some implementations, there is a global variable \fBsp\fP
which could be used, e.g., if the screen were only initialized
-using \fBinitscr\fP.
+using \fB\%initscr\fP.
.bP
-The portable part of \fBexit_terminfo\fP can be freed using \fBdel_curterm\fP.
+The portable part of \fB\%exit_terminfo\fP can be freed using
\fB\%del_curterm\fP.
.IP
-In this case, there is a global variable \fBcur_term\fP which can be
+In this case, there is a global variable \fB\%cur_term\fP which can be
used as parameter.
.SH SEE ALSO
-\fBcurs_initscr\fP(3X),
-\fBcurs_terminfo\fP(3X).
-\fBcurses\fP(3X).
+\fB\%curs_initscr\fP(3X),
+\fB\%curs_terminfo\fP(3X).
+\fB\%curses\fP(3X).
diff --git a/man/curs_mouse.3x b/man/curs_mouse.3x
index dcbeaf01..666a368c 100644
--- a/man/curs_mouse.3x
+++ b/man/curs_mouse.3x
@@ -96,11 +96,11 @@ .SH SYNOPSIS
.fi
.SH DESCRIPTION
These functions provide an interface to mouse events from
-\fBncurses\fP(3X).
-Mouse events are represented by \fBKEY_MOUSE\fP
-pseudo-key values in the \fBwgetch\fP(3X) input stream.
+\fB\%ncurses\fP(3X).
+Mouse events are represented by \fB\%KEY_MOUSE\fP
+pseudo-key values in the \fB\%wgetch\fP(3X) input stream.
.SS mousemask
-To make mouse events visible, use the \fBmousemask\fP function.
+To make mouse events visible, use the \fB\%mousemask\fP function.
This sets the mouse events to be reported.
By default, no mouse events are reported.
.bP
@@ -165,39 +165,39 @@ .SS Mouse events
.TE
.SS getmouse
Once a class of mouse events has been made visible in a window,
-calling the \fBwgetch\fP function on that window may return
-\fBKEY_MOUSE\fP as an indicator that a mouse event has been queued.
+calling the \fB\%wgetch\fP function on that window may return
+\fB\%KEY_MOUSE\fP as an indicator that a mouse event has been queued.
To read the event data and pop the event off the queue, call
-\fBgetmouse\fP.
+\fB\%getmouse\fP.
This function will return \fBOK\fP if a mouse event
is actually visible in the given window, \fBERR\fP otherwise.
-When \fBgetmouse\fP returns \fBOK\fP, the data deposited as y and
+When \fB\%getmouse\fP returns \fBOK\fP, the data deposited as y and
x in the event structure coordinates will be screen-relative character-cell
coordinates.
The returned state mask will have exactly one bit set to
indicate the event type.
The corresponding data in the queue is marked invalid.
-A subsequent call to \fBgetmouse\fP will retrieve the next older
+A subsequent call to \fB\%getmouse\fP will retrieve the next older
item from the queue.
.SS ungetmouse
-The \fBungetmouse\fP function behaves analogously to \fBungetch\fP.
+The \fB\%ungetmouse\fP function behaves analogously to \fB\%ungetch\fP.
It pushes
-a \fBKEY_MOUSE\fP event onto the input queue, and associates with that event
+a \fB\%KEY_MOUSE\fP event onto the input queue, and associates with that event
the given state data and screen-relative character-cell coordinates.
.SS wenclose
-The \fBwenclose\fP function tests whether a given pair of screen-relative
+The \fB\%wenclose\fP function tests whether a given pair of screen-relative
character-cell coordinates is enclosed by a given window, returning \fBTRUE\fP
if it is and \fBFALSE\fP otherwise.
It is useful for determining what subset of
the screen windows enclose the location of a mouse event.
.SS wmouse_trafo
-The \fBwmouse_trafo\fP function transforms a given pair of coordinates
+The \fB\%wmouse_trafo\fP function transforms a given pair of coordinates
from stdscr-relative coordinates
to coordinates relative to the given window or vice versa.
The resulting stdscr-relative coordinates are not always identical
to window-relative coordinates due to the mechanism to reserve lines on top
or bottom of the screen for other purposes
-(see the \fBripoffline\fP and \fBslk_init\fP(3X) calls, for example).
+(see the \fB\%ripoffline\fP and \fB\%slk_init\fP(3X) calls, for example).
.bP
If the parameter \fIto_screen\fP is \fBTRUE\fP, the pointers
\fIpY, pX\fP must reference the coordinates of a location
@@ -222,32 +222,32 @@ .SS wmouse_trafo
are only replaced by the converted coordinates if the transformation was
successful.
.SS mouse_trafo
-The \fBmouse_trafo\fP function performs the same translation
-as \fBwmouse_trafo\fP,
+The \fB\%mouse_trafo\fP function performs the same translation
+as \fB\%wmouse_trafo\fP,
using stdscr for \fIwin\fP.
.SS mouseinterval
-The \fBmouseinterval\fP function sets the maximum time (in thousands of a
+The \fB\%mouseinterval\fP function sets the maximum time (in thousands of a
second) that can elapse between press and release events for them to
be recognized as a click.
-Use \fBmouseinterval(0)\fP to disable click resolution.
+Use \fB\%mouseinterval(0)\fP to disable click resolution.
This function returns the previous interval value.
-Use \fBmouseinterval(\-1)\fP to obtain the interval without altering it.
+Use \fB\%mouseinterval(\-1)\fP to obtain the interval without altering it.
The default is one sixth of a second.
.SS has_mouse
-The \fBhas_mouse\fP function returns \fBTRUE\fP if the mouse driver has been
+The \fB\%has_mouse\fP function returns \fBTRUE\fP if the mouse driver has been
successfully initialized.
.PP
Note that mouse events will be ignored when input is in cooked mode, and will
cause an error beep when cooked mode is being simulated in a window by a
-function such as \fBgetstr\fP that expects a linefeed for input-loop
+function such as \fB\%getstr\fP that expects a linefeed for input-loop
termination.
.SH RETURN VALUE
-\fBgetmouse\fP and \fBungetmouse\fP
+\fB\%getmouse\fP and \fB\%ungetmouse\fP
return the integer \fBERR\fP upon failure or \fBOK\fP
upon successful completion:
.RS 3
.TP 5
-\fBgetmouse\fP
+\fB\%getmouse\fP
returns an error.
.bP
If no mouse driver was initialized, or
@@ -258,19 +258,19 @@ .SH RETURN VALUE
.bP
It also returns an error if no more events remain in the queue.
.TP 5
-\fBungetmouse\fP
+\fB\%ungetmouse\fP
returns an error if the FIFO is full.
.RE
.PP
-\fBmousemask\fP
+\fB\%mousemask\fP
returns the mask of reportable events.
.PP
-\fBmouseinterval\fP
+\fB\%mouseinterval\fP
returns the previous interval value, unless
the terminal was not initialized.
In that case, it returns the maximum interval value (166).
.PP
-\fBwenclose\fP and \fBwmouse_trafo\fP
+\fB\%wenclose\fP and \fB\%wmouse_trafo\fP
are boolean functions returning \fBTRUE\fP or \fBFALSE\fP depending
on their test result.
.SH PORTABILITY
@@ -305,11 +305,11 @@ .SH PORTABILITY
sent to and received from the terminal.
.IP
For instance
-the SVr4 curses library used the \fBget_mouse\fP capability to tell the
+the SVr4 curses library used the \fB\%get_mouse\fP capability to tell the
terminal which mouse button events it should send,
passing the mouse-button bit-mask to the terminal.
Also, it could ask the terminal
-where the mouse was using the \fBreq_mouse_pos\fP capability.
+where the mouse was using the \fB\%req_mouse_pos\fP capability.
.IP
Those features required a terminal which had been modified to work with curses.
They were not part of the X Consortium's xterm.
@@ -323,11 +323,11 @@ .SH PORTABILITY
making it unnecessary to be concerned about compatibility with the
escape sequences.
.PP
-The feature macro \fBNCURSES_MOUSE_VERSION\fP is provided so the preprocessor
+The feature macro \fB\%NCURSES_MOUSE_VERSION\fP is provided so the preprocessor
can be used to test whether these features are present.
-If the interface is changed, the value of \fBNCURSES_MOUSE_VERSION\fP will be
+If the interface is changed, the value of \fB\%NCURSES_MOUSE_VERSION\fP will be
incremented.
-These values for \fBNCURSES_MOUSE_VERSION\fP may be
+These values for \fB\%NCURSES_MOUSE_VERSION\fP may be
specified when configuring ncurses:
.RS 3
.TP 3
@@ -341,7 +341,7 @@ .SH PORTABILITY
The mask uses 29 bits.
.RE
.PP
-The order of the \fBMEVENT\fP structure members is not guaranteed.
+The order of the \fB\%MEVENT\fP structure members is not guaranteed.
Additional fields may be added to the structure in the future.
.PP
Under \fBncurses\fP(3X), these calls are implemented using either
@@ -358,7 +358,7 @@ .SH PORTABILITY
.PP
If you are using an unsupported configuration,
mouse events will not be visible to
-\fBncurses\fP(3X) (and the \fBmousemask\fP function will always
+\fBncurses\fP(3X) (and the \fB\%mousemask\fP function will always
return \fB0\fP).
.PP
If the terminfo entry contains a \fBXM\fP string,
@@ -382,37 +382,37 @@ .SH PORTABILITY
for use with touch screens (which may be pressure-sensitive) or with
3D-mice/trackballs/power gloves.
.PP
-The \fBALL_MOUSE_EVENTS\fP class does not include \fBREPORT_MOUSE_POSITION\fP.
+The \fB\%ALL_MOUSE_EVENTS\fP class does not include
\fB\%REPORT_MOUSE_POSITION\fP.
They are distinct.
For example, in xterm,
wheel/scrolling mice send position reports as a sequence of
presses of buttons 4 or 5 without matching button-releases.
.SH BUGS
Mouse events under xterm will not in fact be ignored during cooked mode,
-if they have been enabled by \fBmousemask\fP.
+if they have been enabled by \fB\%mousemask\fP.
Instead, the xterm mouse
report sequence will appear in the string read.
.PP
Mouse events under xterm will not be detected correctly in a window with
its keypad bit off, since they are interpreted as a variety of function key.
-Your terminfo description should have \fBkmous\fP set to \*(``\\E[M\*(''
+Your terminfo description should have \fB\%kmous\fP set to \*(``\\E[M\*(''
(the beginning of the response from xterm for mouse clicks).
-Other values for \fBkmous\fP are permitted,
+Other values for \fB\%kmous\fP are permitted,
but under the same assumption,
i.e., it is the beginning of the response.
.PP
Because there are no standard terminal responses that would serve to identify
terminals which support the xterm mouse protocol, \fBncurses\fP assumes that
-if \fBkmous\fP is defined in the terminal description,
+if \fB\%kmous\fP is defined in the terminal description,
or if the terminal description's primary name or aliases
contain the string \*(``xterm\*('',
then the terminal may send mouse events.
-The \fBkmous\fP capability is checked first,
+The \fB\%kmous\fP capability is checked first,
allowing the use of newer xterm mouse protocols
such as xterm's private mode 1006.
.SH SEE ALSO
-\fBcurses\fP(3X),
-\fBcurs_inopts\fP(3X),
-\fBcurs_kernel\fP(3X),
-\fBcurs_slk\fP(3X),
-\fBcurs_variables\fP(3X).
+\fB\%curses\fP(3X),
+\fB\%curs_inopts\fP(3X),
+\fB\%curs_kernel\fP(3X),
+\fB\%curs_slk\fP(3X),
+\fB\%curs_variables\fP(3X).
diff --git a/man/curs_trace.3x b/man/curs_trace.3x
index d9411619..a3189cda 100644
--- a/man/curs_trace.3x
+++ b/man/curs_trace.3x
@@ -80,37 +80,37 @@ .SH DESCRIPTION
as well as applications which use the ncurses libraries.
Some limitations apply:
.bP
-Aside from \fBcurses_trace\fP,
+Aside from \fB\%curses_trace\fP,
the other functions are normally available only with the debugging library
-e.g., \fBlibncurses_g.a\fP.
+e.g., \fB\%libncurses_g.a\fP.
.IP
All of the trace functions may be compiled into any model (shared, static,
-profile) by defining the symbol \fBTRACE\fP.
+profile) by defining the symbol \fB\%TRACE\fP.
.bP
-Additionally, the functions which use \fBcchar_t\fP
+Additionally, the functions which use \fB\%cchar_t\fP
are only available with the wide-character configuration of the libraries.
.SS Functions
The principal parts of this interface are
.bP
-\fBcurses_trace\fP, which selectively enables different tracing features, and
+\fB\%curses_trace\fP, which selectively enables different tracing features, and
.bP
-\fB_tracef\fP, which writes formatted data to the \fItrace\fP file.
+\fB\%_tracef\fP, which writes formatted data to the \fItrace\fP file.
.IP
The other functions either return a pointer to a string-area
(allocated by the corresponding function), or return no value
-(such as \fB_tracedump\fP,
-which implements the screen dump for \fBTRACE_UPDATE\fP).
+(such as \fB\%_tracedump\fP,
+which implements the screen dump for \fB\%TRACE_UPDATE\fP).
The caller should not free these strings,
since the allocation is reused on successive calls.
To work around the problem of a single string-area per function,
some use a buffer-number parameter, telling the library to allocate
additional string-areas.
.PP
-The \fBcurses_trace\fP function is always available,
+The \fB\%curses_trace\fP function is always available,
whether or not the other trace functions are available:
.bP
If tracing is available,
-calling \fBcurses_trace\fP with a nonzero parameter
+calling \fB\%curses_trace\fP with a nonzero parameter
updates the trace mask,
and returns the previous trace mask.
.IP
@@ -118,10 +118,10 @@ .SS Functions
ncurses creates the file \*(``trace\*('' in the current directory for output.
If the file already exists, no tracing is done.
.bP
-If tracing is not available, \fBcurses_trace\fP returns zero (0).
+If tracing is not available, \fB\%curses_trace\fP returns zero (0).
.SS Trace Parameter
The trace parameter is formed by OR'ing
-values from the list of \fBTRACE_\fIxxx\fR definitions in \fB<curses.h>\fR.
+values from the list of \fB\%TRACE_\fIxxx\fR definitions in \fB\%<curses.h>\fR.
These include:
.TP 5
.B TRACE_DISABLE
@@ -130,13 +130,13 @@ .SS Trace Parameter
The library flushes the output file,
but retains an open file-descriptor to the trace file
so that it can resume tracing later if a nonzero parameter is passed
-to the \fBcurses_trace\fP function.
+to the \fB\%curses_trace\fP function.
.TP 5
.B TRACE_TIMES
trace user and system times of updates.
.TP 5
.B TRACE_TPUTS
-trace \fBtputs\fP(3X) calls.
+trace \fB\%tputs\fP(3X) calls.
.TP 5
.B TRACE_UPDATE
trace update actions, old & new screens.
@@ -157,7 +157,7 @@ .SS Trace Parameter
The parameters for each call are traced, as well as return values.
.TP 5
.B TRACE_VIRTPUT
-trace virtual character puts, i.e., calls to \fBaddch\fP.
+trace virtual character puts, i.e., calls to \fB\%addch\fP.
.TP 5
.B TRACE_IEVENT
trace low-level input processing, including timeouts.
@@ -180,13 +180,13 @@ .SS Trace Parameter
.B TRACE_MAXIMUM
maximum trace level, enables all of the separate trace features.
.PP
-Some tracing features are enabled whenever the \fBcurses_trace\fP parameter
+Some tracing features are enabled whenever the \fB\%curses_trace\fP parameter
is nonzero.
Some features overlap.
The specific names are used as a guideline.
.SS Initialization
-These functions check the \fBNCURSES_TRACE\fP environment variable,
-to set the tracing feature as if \fBcurses_trace\fP was called:
+These functions check the \fB\%NCURSES_TRACE\fP environment variable,
+to set the tracing feature as if \fB\%curses_trace\fP was called:
.RS 4
.PP
filter,
@@ -205,15 +205,15 @@ .SS Initialization
.RE
.SS Command-line Utilities
The command-line utilities such as \fBtic\fP(1) provide a verbose option
-which extends the set of messages written using the \fBcurses_trace\fP
function.
-Both of these (\fB\-v\fP and \fBcurses_trace\fP)
-use the same variable (\fB_nc_tracing\fP),
+which extends the set of messages written using the \fB\%curses_trace\fP
function.
+Both of these (\fB\-v\fP and \fB\%curses_trace\fP)
+use the same variable (\fB\%_nc_tracing\fP),
which determines the messages which are written.
.PP
Because the command-line utilities may call initialization functions
-such as \fBsetupterm\fP, \fBtgetent\fP or \fBuse_extended_names\fP,
+such as \fB\%setupterm\fP, \fB\%tgetent\fP or \fB\%use_extended_names\fP,
some of their debugging output may be directed to the \fItrace\fP file
-if the \fBNCURSES_TRACE\fP environment variable is set:
+if the \fB\%NCURSES_TRACE\fP environment variable is set:
.bP
messages produced in the utility are written to the standard error.
.bP
@@ -223,23 +223,23 @@ .SS Command-line Utilities
and fewer diagnostics are provided by the command-line utilities.
.SH RETURN VALUE
Routines which return a value are designed to be used as parameters
-to the \fB_tracef\fP routine.
+to the \fB\%_tracef\fP routine.
.SH PORTABILITY
These functions are not part of the XSI interface.
Some other curses implementations are known to
have similar features,
but they are not compatible with ncurses:
.bP
-SVr4 provided \fBtraceon\fP and \fBtraceoff\fP,
+SVr4 provided \fB\%traceon\fP and \fB\%traceoff\fP,
to control whether debugging information was written
to the \*(``trace\*('' file.
While the functions were always available,
this feature was only enabled
-if \fBDEBUG\fP was defined when building the library.
+if \fB\%DEBUG\fP was defined when building the library.
.IP
The SVr4 tracing feature is undocumented.
.bP
-PDCurses provides \fBtraceon\fP and \fBtraceoff\fP,
+PDCurses provides \fB\%traceon\fP and \fB\%traceoff\fP,
which (like SVr4) are always available,
and enable tracing
to the \*(``trace\*('' file
@@ -254,8 +254,8 @@ .SH PORTABILITY
.bP
NetBSD does not provide functions for enabling/disabling traces.
It uses environment variables
-\fBCURSES_TRACE_MASK\fP and
-\fBCURSES_TRACE_FILE\fP to determine what is traced,
+\fB\%CURSES_TRACE_MASK\fP and
+\fB\%CURSES_TRACE_FILE\fP to determine what is traced,
and where the results are written.
This is available only when a debug-library is built.
.IP
@@ -272,4 +272,4 @@ .SH PORTABILITY
The original \fBtrace\fP routine was deprecated because
it often conflicted with application names.
.SH SEE ALSO
-\fBcurses\fP(3X).
+\fB\%curses\fP(3X).
--
2.30.2
signature.asc
Description: PGP signature
- [PATCH 2/9] Protect literals from hyphenation.,
G. Branden Robinson <=