See this post here for a demo:

If you type a hashtag (eg: #hashtag) directly after a forward slash (/) it doesn't become a clickable link. I feel like it should!
Two other combinations which aren't linked (but should) are )#test and _#test.
Demo:

This is not unindended. They could be part of a preceding URL.
Especially the /#test variant I see over and over again in introductions. We should check from the context whether or not the construct is actually part of a URL.
Mentions after / arent converted to an mention.

If the goal is to prevent mentions/hashtags in links without a HTTP(S), there are a lot more cases necessary to handle; for example
example.com/?acct=@me
will be turned into a mention of @me if that account exists on the server.
If the goal is just to prevent mentions/hashtags in links WITH an HTTP(S) scheme, I believe this to be unnecessary;
http://example.com/=#text
generates a single link with no hashtag even though hashtag detection does take effect for
example.com/=#text
(with no HTTP).
Certainly I have tried mentioning multiple accounts before; eg,
Hey @account1/@account2 what are your thoughts on this?
and been confounded when only the first mention actually went through.
I don't think there's any intent here, this is just a buggy twitter::text regex
On Sun, Jun 9, 2019, 9:27 PM KIBI Gô ♀ notifications@github.com wrote:
If the goal is to prevent mentions/hashtags in links without a HTTP(S),
there are a lot more cases necessary to handle; for exampleexample.com/?acct=@me
will be turned into a mention of @me if that account exists on the server.
If the goal is just to prevent mentions/hashtags in links WITH an HTTP(S)
scheme, I believe this to be unnecessary;generates a single link with no hashtag even though hashtag detection does
take effect forexample.com/=#text
(with no HTTP).
Certainly I have tried mentioning multiple accounts before; eg,
Hey @account1/@account2 what are your thoughts on this?
and been confounded when only the first mention actually went through.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tootsuite/mastodon/issues/1910?email_source=notifications&email_token=AABZCVYVQ627BDYROF4TWSLPZWUZNA5CNFSM4DH2KPP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXIWSYI#issuecomment-500263265,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABZCVYSEJGG2RFEKM4KP7LPZWUZNANCNFSM4DH2KPPQ
.
we should definitely at the very least fix the @person/@person2 case, that seems egregiously bad
i understand possible urls but url regex should be a separate thing. if there is no domain.tld then it's not a url
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Please remove the wontfix label and keep it open - I still want this fix!
Thank you bot. :D
I didn't notice this issue when I created #9911, here is my text from over there:
Please support "/" as a separator between hashtags in profile bio.
To add an account to the profile directory I wanted to include the following text in the profile bio:
Profile directory tags: #GNU/#Linux, #FreeSoftware/#FOSS, #python/#go/#jsThe result was, that only
#GNU,#FreeSoftwareand#pythonwere rendered as links when viewed on e.g. https://mastodon.social/@intevation, while the other tags were rendered as regular text.
Additionally the account did not show up in the profile directory for e.g.#Linux.
Toots currently behave in the same way, see e.g. https://mastodon.social/@ThomasAH/101466526664361096 (
#improvementis a link,#bugfixis not)For comparison: Mastalab and Twidere both render
#bugfixas a link, Tusky does not.Should I create a separate issue for this? Since I think bio, directory and toots should behave identically, I did not create a new one.
Related example: github creates links for both issues when separated by "/": #1910/#9911
Most helpful comment
Especially the
/#testvariant I see over and over again in introductions. We should check from the context whether or not the construct is actually part of a URL.