Smarter URL detection, not every @ in the middle makes it an e-mail address

[cointastical]

lib/url.js is too aggressive in converting for mailto:

For the #Fediverse, an @ is used to separate namespaces between instance-local on the left, and global instance on the right.

So in Mastodon, for example, @Cointastical@BitcoinHackers.org indicates this is user @Cointasical using the BitcoinHackers.org Mastodon instance.

However, if I put that in a SN reply (or discussion post), lib/url.js converts that into a mailto: link.

I don't know the best way to remedy this. An e-mail address would never begin with an "@", or a "!", so I think a workaround would be to just make the regex or whatever smarter so that a non-alphanumeric first character (albeit, maybe "-" and "_" are permitted as first character in an e-mail username in SMTP, who knows, ... so maybe explicitly look for "@" or "!" as first character and disqualify those as being an e-mail address).

[cointastical]

Interesting to note that Github did it here as well.

This is not just specific to #Fediverse, .... I've seen this @local.namespace@global.namespace convention elsewhere as well.

[huumn]

Nice catch.

[benalleng]

This issue occurs because the gfm plugin is not very exacting and as a result it thinks nearly every url with an @ is an email, so I created custom remark-email and remark-url similar to the mention gfm remark-mention to find emails and urls to be returned as mailto: and links respectively. (still need to add some additional logic to make sure they are all correctly internal vs external)

edit: my initial idea is about items and it is already done, i just need to fix my logic RIP. But I do see the possibility of adding logic for things like in #170 I think they were just all being held back by the very basic logic of the remark-gfm library

[benalleng]

I noticed that the parseInternalLinks() logic works only one way turning urls into item numbers #n as a link. What do we think about adding a remark-item that parses for a #n in the form as well adding github-like functionality?

[huumn]

I noticed that the parseInternalLinks() logic works only one way turning urls into item numbers #n as a link. What do we think about adding a remark-item that parses for a #n in the form as well adding github-like functionality?

I don't think anyone would use it that way unless it did github like autocompletion. The numbers are getting big and aren't very memorable imo. So I think adding only number parsing isn't a solution to anything in particular.

---

Tangent: if you ever feel strongly that I'm wrong, please tell me. I mostly see my role as sharing experience with regard to these types of things. I can definitely be wrong and I want to be told so when I am, but I will defend my point of view with my experience and plans all the same.

[benalleng]

So I think adding only number parsing isn't a solution to anything in particular.

No I agree with you here, the more I think about it the more niche I think it would be, especially as items begin incrementing faster and faster with users you'd essentially already have to know the note you are looking for and you might as well just copy paste at that point

[benalleng]

if you ever feel strongly that I'm wrong, please tell me.

Will do! I'm still learning your vision for stacker news so every question I ask I can get a better picture. Have patience as I ask the obvious ones as they will be pretty basic for a while probably