Thanks for looking at this patch. Here are a few comments:
if both word parts resulted in suggestions, the collation made no sense.
This is a problem with collations in general: By default, it simply mashes the top corrections together, often resulting in nonsense. The solution is to set "spellcheck.maxCollationTries" to a non-zero value. Doing so will cause the spellchecker to vet the collation possibilities against the index, resulting in collations that are guaranteed to generate hits.
"spe llcheck" would give suggestions "spa" and "spellcheck" and collate this into "spa spellcheck"
This is surprising to me and might indicate a bug. This patch is designed to carefully ensure that when building collations, the corrections do not overlap one another. For instance if "q=spe llcheck" and it gives corrections of "spe>spa" and "spe llcheck>spellcheck", it should not collate these to "q=spa spellcheck" because "spe" overlaps with "spe llcheck". So if you can describe in detail what you're indexing and querying (maybe paste the resulting xml), it would be help me figure out what's going on. Better yet, if you can write a failing unit test and post a patch...
I never got any results back when one of the parts had a typo. So "spe llchek" would not give any suggestions.
This patch does not have the ability to first correct a word fragment and then combine it with another fragment to make a corrected word. Possibly this would be a good next step after what we've got here already gets worked out.
it would also be handy if "spell check" would result in the suggestion "spellcheck". Or is this already possible?
This is the core of what this issue (really
LUCENE-3523) is all about, provided that "spellcheck" is in the dictionary&index you're using.