Slide version: 5.7.3
Android version: 7.0
This comment:

Would render as this:

In the comment search view.
If the comment has a less-than sign without a closing greater-than sign, any text after the less-than sign will not be visible in the comment search view.
eck. Yeah this will happen. <two> looks like an HTML tag, and parsing out unclosed/irregular tags is a pain. Try typing <two> into GitHub even and commenting. It won't appear in the text because it thinks it's HTML.
The fact it DOES find it but does not show it may be an actual fault (I notice if I type "t" for "<test2>" it shows "<test2>" but if I type "te" it shows "<test2>") and not correct.
I am confident in the world's ability to parse out never-closed HTML tags. I am equally confident it will introduce bugs. Not that we shouldn't try anyway.
My most immediate thought is to immediately find ALL HTML tags, then iterate through them all front-to-back to find all matches and drop all non-matches. All "valid" HTML will match. All "invalid" will not and will display as text. This could cause issues because an "invalid" <div> tag will match with the wrong</div>and then the wrong <div>will display. A solution would be to be check if more than one instance of the opening/closing tag exists, and if it does, assume it is real HTML if there is a closing tag ANYWHERE, otherwise assume it's not and just display it
The rabbit hole I just went down here is painful.
@ccrama how do you even do this now in the comment section? Do we just assume ANYTHING the user types is not HTML?
@PiwwowPants right now I just check the text against the body, not the body html, so users are able to search within links and tags or search the original formatting. All I have to do is html unescape the body (turning < into "<") and it'll work :)
Fixed
But now what will I do with my costly and poor performant regex blocks I wrote to find all non-unique HTML tags and assume they're invalid!
What if users want every post to take about 3 seconds to open!?
If that works though cool, otherwise I have my sick regex backup plan.
Hahaha we can implement that regex parser when we bind the cell views, should only see a little performance hit but that sick regex though
Most helpful comment
Fixed