summaryrefslogtreecommitdiffstats
path: root/contrib/ncurses/doc
diff options
context:
space:
mode:
authorrafan <rafan@FreeBSD.org>2007-12-30 11:08:14 +0000
committerrafan <rafan@FreeBSD.org>2007-12-30 11:08:14 +0000
commit9f9e55f97a716ef0dd4082c4cef00a5a95b624a9 (patch)
tree319eb1471eaf8c0c9cfc606e7cb8987ca9167507 /contrib/ncurses/doc
parent7ed1a8e865bedf5154163476c1224b868257ab1a (diff)
downloadFreeBSD-src-9f9e55f97a716ef0dd4082c4cef00a5a95b624a9.zip
FreeBSD-src-9f9e55f97a716ef0dd4082c4cef00a5a95b624a9.tar.gz
Import ncurses 5.6-20071222 snapshot onto the vender branch
Diffstat (limited to 'contrib/ncurses/doc')
-rw-r--r--contrib/ncurses/doc/hackguide.doc2
-rw-r--r--contrib/ncurses/doc/html/ncurses-intro.html36
-rw-r--r--contrib/ncurses/doc/ncurses-intro.doc33
3 files changed, 39 insertions, 32 deletions
diff --git a/contrib/ncurses/doc/hackguide.doc b/contrib/ncurses/doc/hackguide.doc
index ddd7521..8e0ba5c 100644
--- a/contrib/ncurses/doc/hackguide.doc
+++ b/contrib/ncurses/doc/hackguide.doc
@@ -261,7 +261,7 @@ Library Overview
lib_tracedmp.c lib_tracemse.c trace_buf.c
It is rather unlikely you will ever need to change these, unless you
- want to introduce a new debug trace level for some reasoon.
+ want to introduce a new debug trace level for some reason.
There is another group of files that do direct I/O via tputs(),
computations on the terminal capabilities, or queries to the OS
diff --git a/contrib/ncurses/doc/html/ncurses-intro.html b/contrib/ncurses/doc/html/ncurses-intro.html
index e62ead7..451e7ab 100644
--- a/contrib/ncurses/doc/html/ncurses-intro.html
+++ b/contrib/ncurses/doc/html/ncurses-intro.html
@@ -1,8 +1,8 @@
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN">
<!--
- $Id: ncurses-intro.html,v 1.41 2005/12/24 15:47:05 tom Exp $
+ $Id: ncurses-intro.html,v 1.43 2007/03/03 19:31:50 tom Exp $
****************************************************************************
- * Copyright (c) 1998-2004,2005 Free Software Foundation, Inc. *
+ * Copyright (c) 1998-2006,2007 Free Software Foundation, Inc. *
* *
* Permission is hereby granted, free of charge, to any person obtaining a *
* copy of this software and associated documentation files (the *
@@ -914,15 +914,14 @@ Here is some sample code for shellout:
<H3><A NAME="xterm">Using NCURSES under XTERM</A></H3>
-A resize operation in X sends SIGWINCH to the application running under xterm.
-The <CODE>ncurses</CODE> library provides an experimental signal
-handler, but in general does not catch this signal, because it cannot
-know how you want the screen re-painted. You will usually have to write the
-SIGWINCH handler yourself. Ncurses can give you some help. <P>
+A resize operation in X sends <CODE>SIGWINCH</CODE> to the application running
+under xterm.
-The easiest way to code your SIGWINCH handler is to have it do an
-<CODE>endwin</CODE>, followed by an <CODE>refresh</CODE> and a screen repaint you code
-yourself. The <CODE>refresh</CODE> will pick up the new screen size from the
+The easiest way to handle <CODE>SIGWINCH</CODE>
+is to do an <CODE>endwin</CODE>,
+followed by an <CODE>refresh</CODE> and a screen repaint you code
+yourself.
+The <CODE>refresh</CODE> will pick up the new screen size from the
xterm's environment. <P>
That is the standard way, of course (it even works with some vendor's curses
@@ -934,8 +933,17 @@ not resize subwindows which must be shrunk.
are limited to the new screen dimensions, and pads <CODE>stdscr</CODE>
with blanks if the screen is larger. <P>
-Finally, ncurses can be configured to provide its own SIGWINCH handler,
-based on <CODE>resizeterm</CODE>.
+The <CODE>ncurses</CODE> library provides a SIGWINCH signal handler,
+which pushes a <CODE>KEY_RESIZE</CODE> via the wgetch() calls.
+When <CODE>ncurses</CODE> returns that code,
+it calls <code>resizeterm</CODE>
+to update the size of the standard screen's window, repainting that
+(filling with blanks or truncating as needed).
+It also resizes other windows,
+but its effect may be less satisfactory because it cannot
+know how you want the screen re-painted.
+You will usually have to write special-purpose code to handle
+<CODE>KEY_RESIZE</CODE> yourself.
<H3><A NAME="screens">Handling Multiple Terminal Screens</A></H3>
@@ -2184,7 +2192,7 @@ These requests treat the list as cyclic; that is, <CODE>REQ_NEXT_PAGE</CODE>
from the last page goes to the first, and <CODE>REQ_PREV_PAGE</CODE> from
the first page goes to the last.
-<H3><A NAME="#ffield">Inter-Field Navigation Requests</A></H3>
+<H3><A NAME="ffield">Inter-Field Navigation Requests</A></H3>
These requests handle navigation between fields on the same page.
@@ -2238,7 +2246,7 @@ of B and C to the right of B. A <CODE>REQ_MOVE_RIGHT</CODE> from A will
go to B only if A, B, and C <EM>all</EM> share the same first line;
otherwise it will skip over B to C.
-<H3><A NAME="#fifield">Intra-Field Navigation Requests</A></H3>
+<H3><A NAME="fifield">Intra-Field Navigation Requests</A></H3>
These requests drive movement of the edit cursor within the currently
selected field.
diff --git a/contrib/ncurses/doc/ncurses-intro.doc b/contrib/ncurses/doc/ncurses-intro.doc
index 3e607e6..85179d1 100644
--- a/contrib/ncurses/doc/ncurses-intro.doc
+++ b/contrib/ncurses/doc/ncurses-intro.doc
@@ -174,7 +174,7 @@ Scope of This Document
The ncurses package was originated by Pavel Curtis. The original
maintainer of this package is Zeyd Ben-Halim <zmbenhal@netcom.com>.
Eric S. Raymond <esr@snark.thyrsus.com> wrote many of the new features
- in versions after 1.8.1 and wrote most of this introduction. Jürgen
+ in versions after 1.8.1 and wrote most of this introduction. Juergen
Pfeifer wrote all of the menu and forms code as well as the Ada95
binding. Ongoing work is being done by Thomas Dickey (maintainer).
Contact the current maintainers at bug-ncurses@gnu.org.
@@ -798,15 +798,9 @@ Hints, Tips, and Tricks
Using NCURSES under XTERM
A resize operation in X sends SIGWINCH to the application running
- under xterm. The ncurses library provides an experimental signal
- handler, but in general does not catch this signal, because it cannot
- know how you want the screen re-painted. You will usually have to
- write the SIGWINCH handler yourself. Ncurses can give you some help.
-
- The easiest way to code your SIGWINCH handler is to have it do an
- endwin, followed by an refresh and a screen repaint you code yourself.
- The refresh will pick up the new screen size from the xterm's
- environment.
+ under xterm. The easiest way to handle SIGWINCH is to do an endwin,
+ followed by an refresh and a screen repaint you code yourself. The
+ refresh will pick up the new screen size from the xterm's environment.
That is the standard way, of course (it even works with some vendor's
curses implementations). Its drawback is that it clears the screen to
@@ -816,8 +810,13 @@ Hints, Tips, and Tricks
limited to the new screen dimensions, and pads stdscr with blanks if
the screen is larger.
- Finally, ncurses can be configured to provide its own SIGWINCH
- handler, based on resizeterm.
+ The ncurses library provides a SIGWINCH signal handler, which pushes a
+ KEY_RESIZE via the wgetch() calls. When ncurses returns that code, it
+ calls resizeterm to update the size of the standard screen's window,
+ repainting that (filling with blanks or truncating as needed). It also
+ resizes other windows, but its effect may be less satisfactory because
+ it cannot know how you want the screen re-painted. You will usually
+ have to write special-purpose code to handle KEY_RESIZE yourself.
Handling Multiple Terminal Screens
@@ -889,11 +888,11 @@ Compatibility with Older Versions
To understand why this is a problem, remember that screen updates are
calculated between two representations of the entire display. The
documentation says that when you refresh a window, it is first copied
- to the virtual screen, and then changes are calculated to update
- the physical screen (and applied to the terminal). But "copied to" is
- not very specific, and subtle differences in how copying works can
- produce different behaviors in the case where two overlapping windows
- are each being refreshed at unpredictable intervals.
+ to the virtual screen, and then changes are calculated to update the
+ physical screen (and applied to the terminal). But "copied to" is not
+ very specific, and subtle differences in how copying works can produce
+ different behaviors in the case where two overlapping windows are each
+ being refreshed at unpredictable intervals.
What happens to the overlapping region depends on what wnoutrefresh()
does with its argument -- what portions of the argument window it
OpenPOWER on IntegriCloud