Things remaining to be done to ispell:

	- The "munchlist" script can actually increase the size of a
	  dictionary.  For example, munching dict.191 (after my bug fixes
	  to it) reduced the number of words by about 40, but increased
	  the number of characters by a small percentage.  This is
	  because munchlist doesn't recognize duplicate suffixes that
	  generate the same result, except for the three special
	  "s-ending" suffixes J, Z, and X.  For example, right now
	  munchlist will make BATHER by adding the R suffix to both
	  BATH and BATHE.  It would be nice if munchlist could recognize
	  the redundancy and reduce its output so that each word was made
	  in only one way.
	- The characters in the -w option should be written to the header
	  of the hash file, and to a header in the personal dictionary,
	  so the user doesn't have to remember to specify them every time.
	- Buildhash should support the -w option.
	- Buildhash, munchlist, icombine, and the expand scripts should use
	  a character other than slash for the flag separator, so that slashes
	  are available to the -w option.  I tend to lean towards commas.
	- It might be nice to support multiple personal dictionaries.  On
	  the other hand, it's pretty easy to combine them with "cat".
	- Good.c should be table-driven, so that it is easier to modify for
	  other languages.  Ideally, it would support prefixes as well.
	- A small amount of string space could be saved if buildhash would
	  combine strings with common suffixes (e.g., "and" could be stored
	  as a pointer to the tail of "bland").
	- (Peter Wan) Ispell should have a "server mode" for large sites, to
	  get rid of the time needed to read in the dictionary.  On System V,
	  this could be accomplished by having the first execution of ispell
	  read the dictionary into a shared-memory region.  Later incarnations
	  would then get the dictionary by just attaching to the region.
	  One problem would be that the dictionary gets modified during
	  the run, so you might still have to do a memory-to-memory copy
	  after the attach.  The size of having two copies of the dictionary
	  might prohibit this on many machines.  Another approach is a
	  message-based "good.c server", but this too would have to deal
	  with the possibility of modifiying the dictionary.
