Closed (fixed)
Project:
Statuses (Social Microblog)
Version:
7.x-1.x-dev
Component:
Tags submodule
Priority:
Minor
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
26 Nov 2011 at 23:13 UTC
Updated:
4 Jan 2014 at 01:39 UTC
Jump to comment: Most recent
Comments
Comment #1
carlos_lopez_trevonio commentedWell, actually statuses inserts the new term but still shows the word as plain text.
Comment #2
icecreamyou commentedI can't reproduce this. Maybe it has something to do with an input filter you have running over the statuses?
Comment #3
carlos_lopez_trevonio commentedIt happens when "plain text" is configured as input filter in statuses settings but not when "none" is configured as input filter.
Is that its normal behaviour?
Comment #4
icecreamyou commentedAh, got it. The problem is that the
Convert line breaks into HTML (i.e. <br> and <p>)input filter (which is enabled in the default Plain Text input format) wraps status updates in<p>tags. When the Tags submodule gets the status, it looks like<p>#term status</p>and the sequence>#wordapparently doesn't register as being a separate term. That should be fixable, but the easiest solution short term is to just disable that input filter and use the "Convert line breaks" advanced setting for Statuses instead.Comment #5
carlos_lopez_trevonio commentedWill do that, thanks!
Comment #6
carlos_lopez_trevonio commentedWith your permission changing the status to postponed because the reasons are clear now.
Comment #7
mathankumarc commentedI could see the same issue in FBSS 3.x branch also.
tagging.
Comment #8
icecreamyou commentedThe regex that parses #hashtags/@mentions is super scary:
...and its non-unicode variant:
I have no idea how some of that works. I got help writing it from someone in #regex on Freenode over 2 years ago and I have not touched it since. There are a ton of cases it needs to get right and this is the first time I've come across a case it handles incorrectly.
Comment #9
icecreamyou commentedRe-reading this, it's not so bad. Here's an explanation:
Likely the source of the problem in this issue is that the
(?:\A|(?<=\s))section treats the HTML tag's closing angle bracket as text rather than markup so it assumes that the hashtag is part of a larger word. There is not a generic way to resolve this using regex because explicitly matching against the closing angle bracket would permit tags in cases liketext >#tag textwhich we don't want, and generically matching full HTML tags is impossible.I'm prepared to chalk it up under "known problems" that tags won't work without square brackets immediately following HTML markup, which I think is acceptable given that we have an explicit workaround already for the single case where this is likely to occur. I documented this case.