* sale, use or other dealings in this Software without prior written *
* authorization. *
****************************************************************************
- * @Id: curs_add_wch.3x,v 1.26 2020/02/02 23:34:34 tom Exp @
+ * @Id: curs_add_wch.3x,v 1.27 2020/03/22 00:25:15 tom Exp @
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
</PRE><H2><a name="h2-RETURN-VALUE">RETURN VALUE</a></H2><PRE>
All routines return the integer <STRONG>ERR</STRONG> upon failure and <STRONG>OK</STRONG> on success.
- Functions with a "mv" prefix first perform a cursor movement using
+ X/Open does not define any error conditions. This implementation
+ returns an error
+
+ <STRONG>o</STRONG> if the window pointer is null or
+
+ <STRONG>o</STRONG> if it is not possible to add a complete character in the window.
+
+ The latter may be due to different causes:
+
+ <STRONG>o</STRONG> If <STRONG>scrollok</STRONG> is not enabled, writing a character at the lower right
+ margin succeeds. However, an error is returned because it is not
+ possible to wrap to a new line
+
+ <STRONG>o</STRONG> If an error is detected when converting a multibyte character to a
+ sequence of bytes, or if it is not possible to add all of the
+ resulting bytes in the window, an error is returned.
+
+ Functions with a "mv" prefix first perform a cursor movement using
<STRONG>wmove</STRONG>, and return an error if the position is outside the window, or if
the window pointer is null.
</PRE><H2><a name="h2-PORTABILITY">PORTABILITY</a></H2><PRE>
- All of these functions are described in the XSI Curses standard, Issue
- 4. The defaults specified for line-drawing characters apply in the
+ All of these functions are described in the XSI Curses standard, Issue
+ 4. The defaults specified for line-drawing characters apply in the
POSIX locale.
- X/Open Curses makes it clear that the WACS_ symbols should be defined
+ X/Open Curses makes it clear that the WACS_ symbols should be defined
as a pointer to <STRONG>cchar_t</STRONG> data, e.g., in the discussion of <STRONG>border_set</STRONG>. A
few implementations are problematic:
<STRONG>o</STRONG> NetBSD curses defines the symbols as a <STRONG>wchar_t</STRONG> within a <STRONG>cchar_t</STRONG>.
<STRONG>o</STRONG> HPUX curses equates some of the <EM>ACS</EM><STRONG>_</STRONG> symbols to the analogous <EM>WACS</EM><STRONG>_</STRONG>
- symbols as if the <EM>ACS</EM><STRONG>_</STRONG> symbols were wide characters. The misde-
- fined symbols are the arrows and other symbols which are not used
+ symbols as if the <EM>ACS</EM><STRONG>_</STRONG> symbols were wide characters. The misde-
+ fined symbols are the arrows and other symbols which are not used
for line-drawing.
X/Open Curses does not define symbols for thick- or double-lines. SVr4
- curses implementations defined their line-drawing symbols in terms of
- intermediate symbols. This implementation extends those symbols, pro-
+ curses implementations defined their line-drawing symbols in terms of
+ intermediate symbols. This implementation extends those symbols, pro-
viding new definitions which are not in the SVr4 implementations.
- Not all Unicode-capable terminals provide support for VT100-style
+ Not all Unicode-capable terminals provide support for VT100-style
alternate character sets (i.e., the <STRONG>acsc</STRONG> capability), with their corre-
- sponding line-drawing characters. X/Open Curses did not address the
- aspect of integrating Unicode with line-drawing characters. Existing
- implementations of Unix curses (AIX, HPUX, Solaris) use only the <STRONG>acsc</STRONG>
- character-mapping to provide this feature. As a result, those imple-
- mentations can only use single-byte line-drawing characters. Ncurses
- 5.3 (2002) provided a table of Unicode values to solve these problems.
+ sponding line-drawing characters. X/Open Curses did not address the
+ aspect of integrating Unicode with line-drawing characters. Existing
+ implementations of Unix curses (AIX, HPUX, Solaris) use only the <STRONG>acsc</STRONG>
+ character-mapping to provide this feature. As a result, those imple-
+ mentations can only use single-byte line-drawing characters. Ncurses
+ 5.3 (2002) provided a table of Unicode values to solve these problems.
NetBSD curses incorporated that table in 2010.
In this implementation, the Unicode values are used instead of the ter-
- minal description's <STRONG>acsc</STRONG> mapping as discussed in <STRONG><A HREF="ncurses.3x.html">ncurses(3x)</A></STRONG> for the
- environment variable <STRONG>NCURSES_NO_UTF8_ACS</STRONG>. In contrast, for the same
+ minal description's <STRONG>acsc</STRONG> mapping as discussed in <STRONG><A HREF="ncurses.3x.html">ncurses(3x)</A></STRONG> for the
+ environment variable <STRONG>NCURSES_NO_UTF8_ACS</STRONG>. In contrast, for the same
cases, the line-drawing characters described in <STRONG><A HREF="curs_addch.3x.html">curs_addch(3x)</A></STRONG> will use
only the ASCII default values.
- Having Unicode available does not solve all of the problems with line-
+ Having Unicode available does not solve all of the problems with line-
drawing for curses:
- <STRONG>o</STRONG> The closest Unicode equivalents to the VT100 graphics <EM>S1</EM>, <EM>S3</EM>, <EM>S7</EM>
- and <EM>S9</EM> frequently are not displayed at the regular intervals which
+ <STRONG>o</STRONG> The closest Unicode equivalents to the VT100 graphics <EM>S1</EM>, <EM>S3</EM>, <EM>S7</EM>
+ and <EM>S9</EM> frequently are not displayed at the regular intervals which
the terminal used.
- <STRONG>o</STRONG> The <EM>lantern</EM> is a special case. It originated with the AT&T 4410
- terminal in the early 1980s. There is no accessible documentation
+ <STRONG>o</STRONG> The <EM>lantern</EM> is a special case. It originated with the AT&T 4410
+ terminal in the early 1980s. There is no accessible documentation
depicting the lantern symbol on the AT&T terminal.
Lacking documentation, most readers assume that a <EM>storm</EM> <EM>lantern</EM> was
intended. But there are several possibilities, all with problems.
- Unicode 6.0 (2010) does provide two lantern symbols: U+1F383 and
- U+1F3EE. Those were not available in 2002, and are irrelevant
- since they lie outside the BMP and as a result are not generally
+ Unicode 6.0 (2010) does provide two lantern symbols: U+1F383 and
+ U+1F3EE. Those were not available in 2002, and are irrelevant
+ since they lie outside the BMP and as a result are not generally
available in terminals. They are not storm lanterns, in any case.
Most <EM>storm</EM> <EM>lanterns</EM> have a tapering glass chimney (to guard against
tipping); some have a wire grid protecting the chimney.
- For the tapering appearance, U+2603 was adequate. In use on a
+ For the tapering appearance, U+2603 was adequate. In use on a
terminal, no one can tell what the image represents. Unicode calls
it a snowman.
- Others have suggested these alternatives: S U+00A7 (section mark),
+ Others have suggested these alternatives: S U+00A7 (section mark),
<STRONG>O</STRONG> U+0398 (theta), <STRONG>O</STRONG> U+03A6 (phi), d U+03B4 (delta), U+2327 (x in a
- rectangle), U+256C (forms double vertical and horizontal), and
+ rectangle), U+256C (forms double vertical and horizontal), and
U+2612 (ballot box with x).
projects / ncurses.git / blobdiff