* resolve the items in the to.do directory

** expand the above into individual requests and handle those requests

* the manual:

** integrate the items in the faqs/ directory into the manual or code
  or similar

*** create a section on flex design, features, etc.

**** we're not adding comments between pattern-action rules; explain
why in the documentation (because the ability exists as per an email
from millaway)

** We've converted the flex manual to texinfo, but some issues remain:

** index flex.texi

** think about dividing flex.texi into more sections and subsections

** Have flex.texi use automakes version info.

** the pro-.man crowd will want a manpage; I don't want to maintain
   one. What to do?  help2man, possibly.

*** jason@thought.net notes that a short description of flex, a
summary of command line options and a reference to the info pages will
probably satisfy the need for a man page

* repackage the distribution

** address lex-replacement: document or provide an option through
   configure for creating lex and libl.a files

** gettextify flex

* test suite

** Rewrite tests/Makefile.in and friends so that users do not need to
   alter it when they add tests

** make test suite more complete

** create a script which sets up a new skeleton test directory with a
   correct .cvsignore file and other such niceties

** explicitly describe the copyright state of the entries in
   tests/. millaway has assigned the rights to the test suite to me
   and so the test suite will be under the flex license.

* move as much skeleton code as possible out of gen.c and into
  flex.skl

* create a uniform memory management API

* figure out whether we want to add the capability to have
  auto-generated backout rules

* C++

** revisit the C++ API. We get requests to make it more complete.

Local Variables:
mode: text
mode: outline-minor
End: