Maybe the method could be protected so if someone doesnt like whatever we default to, they can subclass.
Good idea, I'll fix that.
What will it do if the document doesnt have the field(s)? Return null?
It returns null ... I'll add a test.
What score does the passage get?
I currently leave it at 0 ... maybe we should do NaN? This would give
the formatter a way to detect the "missing highlights"?
If we change the default, some docs need changing: e.g. "If no highlights were found for a document, its value is <code>null</code>"
OK, I'll add a nocommit so I don't forget this ...
In the main loop, this if check could then go? Or maybe this is the place to do this instead?
I'll move it up. I'm not sure the if check can go ... does
BreakIterator ever return nothing?
I think this would be extremely confusing with multiple fields...
Hmmm, true. An app might highlight N fields and then would want to
see null on some of those fields so that it knows to use the other
But I think the more common case is highlighting a big field (eg the
"body" field)? I would lean towards defaulting this on, and adding
setter / or you subclass and override getEmptyHighlight to turn it
on. Hmmm maybe getEmptyHighlight should take the field name...