unwanted reformatting in teasers

With 0.6.11 I’m seeing unwanted formatting in teasers. With the search term fubarBaz:

<span class="sc-em">fubarbaz</span>

This creates two problems for me. First, the original content is markdown and I don’t want HTML inline. Second the original search term was camel-case fubarBaz, but the teaser shows it downcased.

Are either or both of these behaviors configurable? I took a look at https://github.com/fergiemcdowall/search-index/blob/56043708b4b51ce1df120e4ec99125068b13bc8e/lib/search/searcher.js#L408 where the span is rendered. Seems like passing in a function(string) would be a good solution there. But I haven’t yet figured out where the term is lower-cased.

[fergiemcdowall]

Right- but it does at least solve the problem of customisable markup for teasers.

Requirements for teasers are really variable. I wonder if the best way to deal with this is to extract the teaser functionality out of the core and instead concentrate on a customisable query-result pipeline.

[mblakele]

Thanks, but I’m afraid this doesn’t fix either problem. Matches are still downcased, which makes results look funny. For example I have a section header “Introduction” but if it’s highlighted in search results it’s “introduction”. The teaserHighlighter function only gets “introduction”: it doesn’t have enough information about what the original text was.

Matching text that overlaps with markup, as described above, is still a problem. I’m still using markdown and fubar: baz is now better — but now matches in backquotes or other balanced markdown are a problem. I don’t see a way to fix this in teaserHighlighter because it doesn’t know that it’s in a backquote context so it can’t make any adjustments.

Besides capitalization and markup context, there are also problems with matches on stemmed words: for example “condition” vs “conditions”. The teaserHighlighter only gets “condition” so it’s highlighted as conditions with a non-bolded “s” at the end.

It might help somewhat if teaserHighlighter received a second argument that gave the raw text. Plurals and other stemming could still be a problem though. In the long run highlighting needs access to the original text, and some idea of what the matching search term was and which text it matched.