home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Fred Fish Collection 1.5
/
ffcollection-1-5-1992-11.iso
/
ff_progs
/
txttools
/
ispell.lzh
/
ISPELL
/
WISHES
< prev
Wrap
Text File
|
1991-08-16
|
2KB
|
39 lines
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.