anchor.diff:  
   4. Variables from the file that included that file using the
      `subninja` keyword.
  +
  +Future work
  +-----------
  +
  +Some pieces I'd like to add:
  +
  +_inotify_.  I had originally intended to make Ninja be memory-resident
  +and to use `inotify` to keep the build state hot at all times.  But
  +upon writing the code I found it was fast enough to run from scratch
  +each time.  Perhaps a slower computer would still benefit from
  +inotify; the data structures are set up such that using inotify
  +shouldn't be hard.
  +
  +_build estimation and analysis_.  As part of build correctness, Ninja
  +keeps a log of the time spent on each build statement.  This log
  +format could be adjusted to instead store timing information across
  +multiple runs.  From that, the total time necessary to build could be
  +estimated, allowing Ninja to print status like "3 minutes until
  +complete" when building.  Additionally, a tool could output which
  +commands are the slowest or which directories take the most time
  +to build.
  +
  +_many others_.  See the `todo` file included in the distribution.
  
positive.code: Many projects find make alone adequate for their build problems.  In
  contrast, Ninja has almost no features; just those necessary to get
  builds correct while punting most complexity to generation of the
  ninja input files.
  
  Here are some of the features ninja adds to make.  (These sorts of
  features can often be implemented using more complicated Makefiles,
  
negative.code: where `target` is a known output described by `build.ninja` in the
  current directory.
  
  There is no installation step; the only files of interest to a user
  are the resulting binary and this manual.
  
  
  Creating .ninja files
  