[Question/Feature Request]Why it is intended to not strip ending "t.co" link in text content if it contains line terminators?

[rizutazu]

For example, https://x.com/XHandles/status/1979714051665260601 . In twitter it is displayed as:

Handles are coming...

Join the waitlist at http://handles.x.com/

api.vxtwitter.com returns:

"text": "Handles are coming...\n\nJoin the waitlist at http://handles.x.com https://t.co/XOa9b2lfkN",

the ending "t.co" link https://t.co/XOa9b2lfkN is not stripped.

At https://github.com/dylanpdx/BetterTwitFix/blob/main/utils.py#L6

endTCOregex = re.compile("(^.*?) +https:\/\/t.co\/.*?$")

. matches any character (except for line terminators) (quoted from regex101)

By "intended to not strip", I mean some test cases in https://github.com/dylanpdx/BetterTwitFix/blob/main/vx_testdata.py explicitly preserved ending "t.co" link.

I hope these links to be removed as if there were no line terminators.

[dylanpdx]

Looks like this is a bug, will add a fix soon

[rizutazu]

Hi, sorry to bother, i think i've found out two more cases that did not work as expected as well:

1. tweets with media solely, no text content. For example: https://x.com/ShouldHaveCat/status/1985030300502491556 , "t.co" is not stripped
2. an edge case: tweets like abcabc t.co/?arg=1 . I've tested in twitter web, it can correctly display "t.co/?arg=1" link at the end (well, this case is so weird, there might be nobody tweet such content), but the api will incorrectly strip it.

Seems like response from api.x.com has field display_text_range , it might be useful and make it more robust