diff --git a/doc/hackguide.doc b/doc/hackguide.doc
index 8e0ba5c..a464d03 100644
--- a/doc/hackguide.doc
+++ b/doc/hackguide.doc
@@ -1,6 +1,8 @@
                           A Hacker's Guide to NCURSES
 
-                                   Contents
+A Hacker's Guide to NCURSES
+
+Contents
 
      * Abstract
      * Objective of the Package
@@ -24,7 +26,7 @@
      * Style Tips for Developers
      * Porting Hints
 
-                                   Abstract
+Abstract
 
    This document is a hacker's tour of the ncurses library and utilities.
    It  discusses  design  philosophy,  implementation  methods,  and  the
@@ -32,7 +34,7 @@
    reading  for  anyone  who  is  interested  in  porting,  extending  or
    improving the package.
 
-                           Objective of the Package
+Objective of the Package
 
    The objective of the ncurses package is to provide a free software API
    for character-cell terminals and terminal emulators with the following
@@ -52,7 +54,7 @@
    cannot  add  features  if  it  means  breaking  the portion of the API
    corresponding to historical curses versions.
 
-Why System V Curses?
+  Why System V Curses?
 
    We  used System V curses as a model, reverse-engineering their API, in
    order to fulfill the first two objectives.
@@ -65,7 +67,7 @@
    X/Open  is  explicitly and closely modeled on System V. So conformance
    with System V took us most of the way to base-level XSI conformance.
 
-How to Design Extensions
+  How to Design Extensions
 
    The  third  objective (standards conformance) requires that it be easy
    to  condition  source  code  using  ncurses  so  that  the  absence of
@@ -80,7 +82,7 @@
    does  not  define, but which is defined in the ncurses library header.
    You can use this to condition the calls to the mouse API calls.
 
-                         Portability and Configuration
+Portability and Configuration
 
    Code  written  for  ncurses may assume an ANSI-standard C compiler and
    POSIX-compatible  OS  interface.  It may also assume the presence of a
@@ -101,7 +103,7 @@
    specification  files  (configure.in  and  aclocal.m4)  to set up a new
    feature macro, which you then use to condition your code.
 
-                           Documentation Conventions
+Documentation Conventions
 
    There  are  three kinds of documentation associated with this package.
    Each has a different preferred format:
@@ -111,7 +113,7 @@
 
    Our conventions are simple:
     1. Maintain package-internal files in plain text. The expected viewer
-       for  them  more(1)  or  an  editor  window;  there's  no  point in
+       for  them  is  more(1)  or  an editor window; there is no point in
        elaborate mark-up.
     2. Mark  up manual pages in the man macros. These have to be viewable
        through traditional man(1) programs.
@@ -120,14 +122,14 @@
    When  in  doubt,  HTMLize  a  master and use lynx(1) to generate plain
    ASCII (as we do for the announcement document).
 
-   The reason for choosing HTML is that it's (a) well-adapted for on-line
-   browsing through viewers that are everywhere; (b) more easily readable
-   as  plain  text  than most other mark-ups, if you don't have a viewer;
-   and   (c)   carries   enough  information  that  you  can  generate  a
+   The  reason  for  choosing  HTML  is  that  it is (a) well-adapted for
+   on-line  browsing through viewers that are everywhere; (b) more easily
+   readable  as plain text than most other mark-ups, if you do not have a
+   viewer;  and  (c)  carries  enough information that you can generate a
    nice-looking  printed  version  from  it.  Also,  of  course,  it make
    exporting things like the announcement document to WWW pretty trivial.
 
-                              How to Report Bugs
+How to Report Bugs
 
    The  reporting  address  for  bugs  is  bug-ncurses@gnu.org. This is a
    majordomo  list;  to join, write to bug-ncurses-request@gnu.org with a
@@ -135,16 +137,16 @@
              subscribe <name>@<host.domain>
 
    The  ncurses  code is maintained by a small group of volunteers. While
-   we  try  our  best to fix bugs promptly, we simply don't have a lot of
+   we  try  our best to fix bugs promptly, we simply do not have a lot of
    hours  to  spend  on  elementary  hand-holding. We rely on intelligent
    cooperation  from  our  users.  If  you  think you have found a bug in
    ncurses,  there  are some steps you can take before contacting us that
    will help get the bug fixed quickly.
 
    In  order  to  use  our bug-fixing time efficiently, we put people who
-   show us they've taken these steps at the head of our queue. This means
-   that  if you don't, you'll probably end up at the tail end and have to
-   wait a while.
+   show  us  they  have  taken these steps at the head of our queue. This
+   means that if you do not, you will probably end up at the tail end and
+   have to wait a while.
     1. Develop a recipe to reproduce the bug.
        Bugs  we  can reproduce are likely to be fixed very quickly, often
        within  days.  The most effective single thing you can do to get a
@@ -155,17 +157,17 @@
     2. Try to reproduce the bug on a different terminal type.
        In  our experience, most of the behaviors people report as library
        bugs are actually due to subtle problems in terminal descriptions.
-       This is especially likely to be true if you're using a traditional
-       asynchronous  terminal  or PC-based terminal emulator, rather than
-       xterm or a UNIX console entry.
-       It's therefore extremely helpful if you can tell us whether or not
-       your  problem  reproduces  on other terminal types. Usually you'll
-       have  both  a  console  type  and  xterm available; please tell us
+       This  is  especially  likely  to  be  true  if  you  are  using  a
+       traditional  asynchronous  terminal or PC-based terminal emulator,
+       rather than xterm or a UNIX console entry.
+       It  is  therefore  extremely helpful if you can tell us whether or
+       not  your  problem reproduces on other terminal types. Usually you
+       will  have both a console type and xterm available; please tell us
        whether or not your bug reproduces on both.
        If  you  have  xterm  available,  it is also good to collect xterm
        reports for different window sizes. This is especially true if you
        normally  use  an unusual xterm window size -- a surprising number
-       of the bugs we've seen are either triggered or masked by these.
+       of the bugs we have seen are either triggered or masked by these.
     3. Generate and examine a trace file for the broken behavior.
        Recompile   your  program  with  the  debugging  versions  of  the
        libraries.  Insert  a  trace()  call  with  the  argument  set  to
@@ -178,35 +180,35 @@
        tell  you  immediately if this is happening, and save you from the
        possible  embarrassment of being told that the bug is in your code
        and is your problem rather than ours.
-       If  the  virtual-screen  dumps  look correct but the bug persists,
-       it's  possible  to  crank up the trace level to give more and more
+       If  the virtual-screen dumps look correct but the bug persists, it
+       is  possible  to  crank  up  the trace level to give more and more
        information  about  the  library's  update actions and the control
        sequences  it  issues  to  perform them. The test directory of the
        distribution contains a tool for digesting these logs to make them
        less tedious to wade through.
-       Often you'll find terminfo problems at this stage by noticing that
-       the  escape  sequences put out for various capabilities are wrong.
-       If  not,  you're likely to learn enough to be able to characterize
-       any bug in the screen-update logic quite exactly.
+       Often  you  will  find terminfo problems at this stage by noticing
+       that  the  escape  sequences  put out for various capabilities are
+       wrong.  If  not,  you  are  likely  to  learn enough to be able to
+       characterize any bug in the screen-update logic quite exactly.
     4. Report details and symptoms, not just interpretations.
-       If  you  do the preceding two steps, it is very likely that you'll
+       If you do the preceding two steps, it is very likely that you will
        discover the nature of the problem yourself and be able to send us
        a  fix.  This  will  create happy feelings all around and earn you
-       good  karma for the first time you run into a bug you really can't
+       good karma for the first time you run into a bug you really cannot
        characterize and fix yourself.
-       If  you're  still  stuck,  at  least  you'll know what to tell us.
+       If  you  are  still stuck, at least you will know what to tell us.
        Remember,  we  need  details.  If  you guess about what is safe to
        leave out, you are too likely to be wrong.
        If  your  bug  produces a bad update, include a trace file. Try to
        make  the  trace  at the least voluminous level that pins down the
-       bug.  Logs  that  have  been through tracemunch are OK, it doesn't
-       throw   away   any   information  (actually  they're  better  than
-       un-munched ones because they're easier to read).
+       bug.  Logs  that  have been through tracemunch are OK, it does not
+       throw   away  any  information  (actually  they  are  better  than
+       un-munched ones because they are easier to read).
        If  your bug produces a core-dump, please include a symbolic stack
        trace generated by gdb(1) or your local equivalent.
-       Tell us about every terminal on which you've reproduced the bug --
-       and  every  terminal on which you can't. Ideally, sent us terminfo
-       sources for all of these (yours might differ from ours).
+       Tell  us about every terminal on which you have reproduced the bug
+       --  and  every  terminal  on  which  you  cannot. Ideally, send us
+       terminfo sources for all of these (yours might differ from ours).
        Include  your ncurses version and your OS/machine type, of course!
        You can find your ncurses version in the curses.h file.
 
@@ -219,8 +221,8 @@
    The   most  important  of  these  is  mvcur,  a  test  frame  for  the
    cursor-movement  optimization  code.  With  this  program, you can see
    directly  what  control sequences will be emitted for any given cursor
-   movement or scroll/insert/delete operations. If you think you've got a
-   bad  capability  identified,  you  can  disable it and test again. The
+   movement or scroll/insert/delete operations. If you think you have got
+   a  bad  capability  identified, you can disable it and test again. The
    program is command-driven and has on-line help.
 
    If  you think the vertical-scroll optimization is broken, or just want
@@ -228,9 +230,9 @@
    comments  of hardscroll.c and hashmap.c; then try it out. You can also
    test the hardware-scrolling optimization separately with hardscroll.
 
-                         A Tour of the Ncurses Library
+A Tour of the Ncurses Library
 
-Library Overview
+  Library Overview
 
    Most  of  the  library is superstructure -- fairly trivial convenience
    interfaces  to a small set of basic functions and data structures used
@@ -290,8 +292,9 @@
      lib_mouse.c lib_mvcur.c lib_refresh.c lib_setup.c lib_vidattr.c
 
    Most  of  the  algorithmic  complexity  in  the library lives in these
-   files.  If  there is a real bug in ncurses itself, it's probably here.
-   We'll tour some of these files in detail below (see The Engine Room).
+   files.  If there is a real bug in ncurses itself, it is probably here.
+   We  will  tour  some  of  these  files in detail below (see The Engine
+   Room).
 
    Finally,  there  is  a  group  of  files  that is actually most of the
    terminfo  compiler.  The reason this code lives in the ncurses library
@@ -300,11 +303,11 @@
      alloc_entry.c  captoinfo.c  comp_captab.c  comp_error.c comp_hash.c
      comp_parse.c comp_scan.c parse_entry.c read_termcap.c write_entry.c
 
-   We'll discuss these in the compiler tour.
+   We will discuss these in the compiler tour.
 
-The Engine Room
+  The Engine Room
 
-  Keyboard Input
+    Keyboard Input
 
    All  ncurses  input  funnels through the function wgetch(), defined in
    lib_getch.c.  This function is tricky; it has to poll for keyboard and
@@ -323,10 +326,11 @@
 
    Hackers  bruised  by  previous encounters with variant select(2) calls
    may  find  the  code  in  lib_twait.c  interesting.  It deals with the
-   problem that some BSD selects don't return a reliable time-left value.
-   The function timed_wait() effectively simulates a System V select.
+   problem  that  some  BSD  selects  do  not return a reliable time-left
+   value.  The  function  timed_wait()  effectively  simulates a System V
+   select.
 
-  Mouse Events
+    Mouse Events
 
    If the mouse interface is active, wgetch() polls for mouse events each
    call,  before  it  goes  to  the  keyboard  for  input.  It  is  up to
@@ -341,19 +345,19 @@
    to  imply having the prefix somewhere in the function-key capabilities
    at terminal-type initialization.
 
-   This  kluge  only  works  because  kmous  isn't  actually  used by any
+   This  kluge  only  works  because  kmous  is  not actually used by any
    historic terminal type or curses implementation we know of. Best guess
-   is  it's  a  relic  of some forgotten experiment in-house at Bell Labs
-   that  didn't  leave  any  traces  in the publicly-distributed System V
+   is  it  is  a relic of some forgotten experiment in-house at Bell Labs
+   that  did  not  leave  any traces in the publicly-distributed System V
    terminfo  files.  If System V or XPG4 ever gets serious about using it
    again, this kluge may have to change.
 
    Here are some more details about mouse event handling:
 
-   The lib_mouse()code is logically split into a lower level that accepts
-   event  reports  in  a  device-dependent format and an upper level that
-   parses mouse gestures and filters events. The mediating data structure
-   is a circular queue of event structures.
+   The  lib_mouse()  code  is  logically  split  into  a lower level that
+   accepts  event reports in a device-dependent format and an upper level
+   that  parses  mouse  gestures  and  filters events. The mediating data
+   structure is a circular queue of event structures.
 
    Functionally, the lower level's job is to pick up primitive events and
    put  them  on  the circular queue. This can happen in one of two ways:
@@ -366,7 +370,7 @@
    accepted to parse the digested mouse reports (low-level events) into a
    gesture (a high-level or composite event).
 
-  Output and Screen Updating
+    Output and Screen Updating
 
    With the single exception of character echoes during a wgetnstr() call
    (which  simulates  cooked-mode line editing in an ncurses window), the
@@ -380,24 +384,23 @@
    The  brains  of this operation are the modules hashmap.c, hardscroll.c
    and  lib_doupdate.c; the latter two use lib_mvcur.c. Essentially, what
    happens looks like this:
-
-   The  hashmap.c  module tries to detect vertical motion changes between
-   the  real  and virtual screens. This information is represented by the
-   oldindex  members  in  the  newscr  structure.  These  are modified by
-   vertical-motion  and  clear  operations,  and  both are re-initialized
-   after each update. To this change-journalling information, the hashmap
-   code  adds  deductions  made using a modified Heckel algorithm on hash
-   values generated from the line contents.
-
-   The  hardscroll.c module computes an optimum set of scroll, insertion,
-   and   deletion   operations  to  make  the  indices  match.  It  calls
-   _nc_mvcur_scrolln() in lib_mvcur.c to do those motions.
-
-   Then  lib_doupdate.c  goes  to  work.  Its  job  is to do line-by-line
-   transformations  of curscr lines to newscr lines. Its main tool is the
-   routine  mvcur()  in  lib_mvcur.c.  This  routine does cursor-movement
-   optimization,  attempting to get from given screen location A to given
-   location B in the fewest output characters possible.
+     * The  hashmap.c  module  tries  to  detect  vertical motion changes
+       between   the  real  and  virtual  screens.  This  information  is
+       represented by the oldindex members in the newscr structure. These
+       are modified by vertical-motion and clear operations, and both are
+       re-initialized  after  each  update.  To  this  change-journalling
+       information,  the  hashmap  code  adds  deductions  made  using  a
+       modified  Heckel  algorithm on hash values generated from the line
+       contents.
+     * The  hardscroll.c  module  computes  an  optimum  set  of  scroll,
+       insertion,  and  deletion operations to make the indices match. It
+       calls _nc_mvcur_scrolln() in lib_mvcur.c to do those motions.
+     * Then  lib_doupdate.c  goes  to work. Its job is to do line-by-line
+       transformations  of curscr lines to newscr lines. Its main tool is
+       the   routine   mvcur()   in   lib_mvcur.c.   This   routine  does
+       cursor-movement  optimization, attempting to get from given screen
+       location  A  to  given  location B in the fewest output characters
+       possible.
 
    If  you  want to work on screen optimizations, you should use the fact
    that  (in  the  trace-enabled  version  of  the  library) enabling the
@@ -411,7 +414,7 @@
    variable  _nc_optimize_enable.  See  the  file include/curses.h.in for
    mask values, near the end.
 
-                         The Forms and Menu Libraries
+The Forms and Menu Libraries
 
    The  forms  and menu libraries should work reliably in any environment
    you  can  port ncurses to. The only portability issue anywhere in them
@@ -419,7 +422,7 @@
    TYPE_REGEXP will recognize.
 
    The  configuration  code  prefers the POSIX regex facility, modeled on
-   System  V's,  but  will  settle  for  BSD  regexps if the former isn't
+   System  V's,  but  will  settle  for  BSD regexps if the former is not
    available.
 
    Historical  note:  the  panels code was written primarily to assist in
@@ -427,7 +430,7 @@
    panels  support; u386mon 2.10 and beyond use it. This version has been
    slightly cleaned up for ncurses.
 
-                        A Tour of the Terminfo Compiler
+A Tour of the Terminfo Compiler
 
    The ncurses implementation of tic is rather complex internally; it has
    to  do  a  trying  combination  of missions. This starts with the fact
@@ -437,12 +440,12 @@
 
    The  implementation  therefore  starts  with a table-driven, dual-mode
    lexical analyzer (in comp_scan.c). The lexer chooses its mode (termcap
-   or terminfo) based on the first `,' or `:' it finds in each entry. The
+   or terminfo) based on the first "," or ":" it finds in each entry. The
    lexer  does  all  the work of recognizing capability names and values;
    the  grammar above it is trivial, just "parse entries till you run out
    of file".
 
-Translation of Non-use Capabilities
+  Translation of Non-use Capabilities
 
    Translation   of  most  things  besides  use  capabilities  is  pretty
    straightforward.   The   lexical   analyzer's   tokenizer  hands  each
@@ -460,23 +463,23 @@
    shareable text space).
 
    Thus, adding a new capability is usually pretty trivial, just a matter
-   of  adding  one  line to the include/Caps file. We'll have more to say
+   of  adding one line to the include/Caps file. We will have more to say
    about this in the section on Source-Form Translation.
 
-Use Capability Resolution
+  Use Capability Resolution
 
-   The  background  problem  that  makes  tic tricky isn't the capability
-   translation  itself,  it's  the  resolution of use capabilities. Older
+   The  background  problem  that  makes tic tricky is not the capability
+   translation  itself,  it  is the resolution of use capabilities. Older
    versions would not handle forward use references for this reason (that
    is, a using terminal always had to follow its use target in the source
    file).  By  doing  this,  they  got  away with a simple implementation
    tactic;  compile  everything  as  it  blows by, then resolve uses from
    compiled entries.
 
-   This  won't  do  for  ncurses.  The  problem  is  that  that the whole
+   This  will  not  do  for  ncurses.  The problem is that that the whole
    compilation  process  has  to  be embeddable in the ncurses library so
    that it can be called by the startup code to translate termcap entries
-   on  the  fly.  The  embedded  version  can't  go promiscuously writing
+   on  the  fly.  The  embedded  version  cannot go promiscuously writing
    everything  it  translates  out  to  disk  --  for  one thing, it will
    typically be running with non-root permissions.
 
@@ -485,7 +488,7 @@
    use  resolution  in-memory  before writing everything out. This design
    has other advantages: it makes forward and back use-references equally
    easy  (so  we get the latter for free), and it makes checking for name
-   collisions before they're written out easy to do.
+   collisions before they are written out easy to do.
 
    And   this  is  exactly  how  the  embedded  version  works.  But  the
    stand-alone  user-accessible  version  of  tic  partly  reverts to the
@@ -502,8 +505,8 @@
    writes  out  the  referenced  entry if it has no use capabilities. The
    compiler  main loop refrains from adding the entry to the in-core list
    when  this hook fires. If some other entry later needs to reference an
-   entry  that  got  written  immediately, that's OK; the resolution code
-   will fetch it off disk when it can't find it in core.
+   entry  that  got  written immediately, that is OK; the resolution code
+   will fetch it off disk when it cannot find it in core.
 
    Name  collisions  will  still  be  detected,  just not as cleanly. The
    write_entry()   code   complains  before  overwriting  an  entry  that
@@ -511,7 +514,7 @@
    complain  about overwriting entries newly made during the tic run, but
    not about overwriting ones that predate it.
 
-Source-Form Translation
+  Source-Form Translation
 
    Another use of tic is to do source translation between various termcap
    and terminfo formats. There are more variants out there than you might
@@ -525,9 +528,9 @@
 
    The  include/Caps  file  has  a header comment describing ways you can
    specify  source  translations  for  nonstandard  capabilities  just by
-   altering the master table. It's possible to set up capability aliasing
-   or  tell  the  compiler  to  plain  ignore  a given capability without
-   writing any C code at all.
+   altering  the  master  table.  It  is  possible  to  set up capability
+   aliasing  or  tell  the  compiler  to  plain ignore a given capability
+   without writing any C code at all.
 
    For  circumstances where you need to do algorithmic translation, there
    are  functions  in  parse_entry.c called after the parse of each entry
@@ -535,7 +538,7 @@
    for  example,  is  where  the AIX box1 capability get translated to an
    acsc string.
 
-                                Other Utilities
+Other Utilities
 
    The  infocmp  utility  is just a wrapper around the same entry-dumping
    code  used  by tic for source translation. Perhaps the one interesting
@@ -547,7 +550,7 @@
    The  tput  and  clear  utilities  just  do an entry load followed by a
    tputs() of a selected capability.
 
-                           Style Tips for Developers
+Style Tips for Developers
 
    See   the  TO-DO  file  in  the  top-level  directory  of  the  source
    distribution for additions that would be particularly useful.
@@ -563,23 +566,23 @@
    Look  for  the  string  FIXME  in  source  files to tag minor bugs and
    potential problems that could use fixing.
 
-   Don't  try  to auto-detect OS features in the main body of the C code.
-   That's the job of the configuration system.
+   Do  not try to auto-detect OS features in the main body of the C code.
+   That is the job of the configuration system.
 
    To hold down complexity, do make your code data-driven. Especially, if
    you  can drive logic from a table filtered out of include/Caps, do it.
    If  you  find  you  need  to augment the data in that file in order to
-   generate  the  proper table, that's still preferable to ad-hoc code --
-   that's why the fifth field (flags) is there.
+   generate  the proper table, that is still preferable to ad-hoc code --
+   that is why the fifth field (flags) is there.
 
    Have fun!
 
-                                 Porting Hints
+Porting Hints
 
    The  following  notes  are intended to be a first step towards DOS and
    Macintosh ports of the ncurses libraries.
 
-   The  following library modules are `pure curses'; they operate only on
+   The  following library modules are "pure curses"; they operate only on
    the  curses  internal  structures,  do all output through other curses
    calls  (not  including  tputs()  and putp()) and do not call any other
    UNIX  routines  such  as  signal(2)  or  the stdio library. Thus, they
@@ -626,7 +629,7 @@
 
    Modules that would have to be modified for a port start here:
 
-   The  following  modules  are  `pure  curses'  but  contain assumptions
+   The  following  modules  are  "pure  curses"  but  contain assumptions
    inappropriate for a memory-mapped port.
 
    lib_longname.c