[ https://issues.apache.org/jira/browse/LUCENE-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066457#comment-13066457 ]
Robert Muir commented on LUCENE-3318: ------------------------------------- {quote} Defaults can always be bad in some cases - else they wouldn't be called defaults - they would just be the way it is. In this case, IMO, it's generally been a fine default for the old highlighter - it's the minority of use cases that have need something else - all you can expect from a good default. {quote} There doesn't need to be defaults at all: i think these differnt ways should be split into independent highlighting methods. we can re-use the same APIs (fragmenters or whatever) across the different implementations, if possible, but why not just force the user to use the algorithm they want? i dont think we need to have ABC+DEFHighlighter that does black magic across different algorithms, you should instead pick ABCHighlighter or DEFHighlighter. this is a library after all, I think this would be much cleaner. > Sketch out highlighting based on term positions / position iterators > -------------------------------------------------------------------- > > Key: LUCENE-3318 > URL: https://issues.apache.org/jira/browse/LUCENE-3318 > Project: Lucene - Java > Issue Type: Sub-task > Components: modules/highlighter > Affects Versions: Positions Branch > Reporter: Simon Willnauer > Assignee: Mike Sokolov > Fix For: Positions Branch > > > Spinn off from LUCENE-2878. Since we have positions on a large number of > queries already in the branch is worth looking at highlighting as a real > consumer of the API. A prototype is already committed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org