-X/Open Curses states regarding \fBdelwin\fP:
-.bP
-It must delete subwindows before deleting their parent.
-.bP
-If \fBdelwin\fP is asked to delete a parent window,
-it can only succeed if the curses library keeps a list of the subwindows.
-SVr4 curses kept a count of the number of subwindows rather than a list.
-It simply returned \fBERR\fP when asked to delete a subwindow.
-Solaris X/Open curses does not even make that check,
-and will delete a parent window which still has subwindows.
-.bP
-Since release 4.0 (1996), ncurses maintains a list of windows for each screen,
-to ensure that a window has no subwindows before allowing deletion.
-.bP
-NetBSD copied this feature of ncurses in 2003.
-.br
-PDCurses follows the scheme used in Solaris X/Open curses.
+Regarding
+.IR \%delwin ","
+X/Open Curses states that
+.RS
+.PP
+[t]he application must delete subwindows before deleting the main
+window.
+.RE
+.PP
+If
+.I \%delwin
+is asked to delete a parent window,
+it can succeed only if the
+.I curses
+library keeps a list of its subwindows.
+SVr4
+.I curses
+kept a count of the number of subwindows rather than a list.
+It simply returned
+.B ERR
+when asked to delete a subwindow.
+Solaris X/Open
+.I curses
+.RI \%( xcurses )
+does not make even that check,
+and will delete a parent window that still has subwindows.
+.I \%PDCurses
+also behaves this way.
+.PP
+.I \%ncurses
+4.0 (1996) and later maintains a list of windows for each screen
+to ensure that a window has no subwindows before allowing its deletion.
+NetBSD
+.I curses
+has followed suit since 2003.
+.PP
+SVr4
+.I curses
+documentation is unclear about what
+.I \%wsyncup
+and
+.I \%wsyncdown
+actually do.
+It seems to imply that they are supposed to touch only those lines that
+are affected by changes to a window's ancestors.
+The description and behavior of these functions in
+.I \%ncurses
+is patterned on the X/Open Curses standard;
+this approach may result in slower updates.