KEY:
* -- easy change
** - harder, needs more understanding
@ -- needs understanding of internals
@@ - mail me if you need this!

* give lqshow the ability to page a file

** make a list of matches showing words nearby in a KWIC style
   so that lqtext can show (say) a dozen at a time...
   (see lqkwik... this will appear fairlysoon, I expect)

@@ special treatment of dates

** table of pagers for browsing by file/type

**@@ Better ranking of queries

**@@ write a manual :-(

**@ "this" can't be accessed by lqword, but can be by lqshow[???].  The
   entire plural code (Root.c) needs a rethink.
   I have started Plurals.c, but it's not ready yet.  Yell if you have any
   ideas, I need them!

* The various Filter routines should be incorporated into showfile. 
* Automatic uncompression should be added.  Should look at the magic number
  as well as the file extension
  ** -- lqshow would need big changes in one (obvious) routine... as it
	currently uses lseek...

** Showfile should be made a routine (BrowseList() I suppose) that takes
** a list of Phrases with their matches...

**@ should abandon dbm for the list of filenames.  A better approach would
   be to store path components as words in the database!  This would make
   / a common-word, though.  Needs some thought.
   A btree might be a good comprimise.  For now, at least ozmahash doesn't
   have overflow problems.

*@ should use six-bit encoding for strings.  This would save a lot of space
   with relatively little overhead.
   Actually it doesn't save space at all, based on my experiments.  Sigh.

**@@ the ability to delete a file.  Two ways:
     1) read the file -- could be an option to addfile, in fact.  This
	would have to check the time-stamps, of course.
     2) schedule (perhaps overnight) a process to go through the entire
	database and delete old files.
	Also, addfile (and SortWordPlaces()) could remove deleted FIDs 
	automatically, which would help.

*@ the algorithm to add a new entry to a WID is too slow, because of the
  requirement that the list be kept sorted.  I should instead keep a
  SortedToHere counter in the header, and simply append new words.
  The next time someone does a getpblock() and a sort, it could be written
  back sorted.  Or there could be a daemon sorter!!

* need better documentation!

* README should be used more, allowing more configuration.
  (README can now be called something else by recompiling)

** allow dynamic definition of word start/mid/end, in README.
   Must be at least as fast as isupper() etc.
   Perhaps per-file-type rules, though?  Makes Phrase Matching hard.

** Better file locking
   (no file locking or signal handling at all at the moment -- I ripped it
    all out when I discovered that it was broken on many systems, and
    this gave a false sense of security.)

* Finish the ReadAhead daemon.   See if it makes an improvement.
  The idea is that whenever ReadBlock reads a block, it should ask the
  daemon to read the next block, thus ensuring that it is in the buffer
  cache.
  It might be better simply to give it the WID and have it read the entire
  chain itself.

* Phrase Matching would be orders of magnitude faster if it did not involve
  reading the tables of matches until they are needed, as many of them
  won't be!  It should extend the lists of matches for each word in the
  phrase only as necessary.

** save large FIDs for large files.

** Use a better number scheme (numbers.c)
   make some more of the number routines inline -- especially use
   a #define for the common case of sReadNumber ad sWriteNumber, eliminating
   millions (!) of funtion calls when the numbers are only 1 byte long.
   Note that most numbers turn out to fit in one byte (more than 90%) at
   the moment, so if I had another bit I could improve the flags stuff..
   The current scheme sets the top bit in each byte if there is more to
   follow.  Another alternative would be to use magic values (e.g.
   256 - (number of bytes)) for the first byte if there's more than one
   byte. Hence 255 255 would be used to store 255.  This would roughly
   double the number of numbers (!) fitting into one byte... hmm...

Known Bugs
==========
* lqshow only marks the first word of the phrase.
* lqshow does not know about file types!!!
* there is no troff (or sqtroff) file type
* the C filter got lost in history (sigh)
* I cannot distribute the CDMS and Uniplex filters
