Autolinks starting with an at sign

[Crissov]

I believe the section on email autolinks could benefit from additional examples that are not autolinks:

<@user>
<@user.at.social>
<@user@fedi.verse>

(The local GFM highlighter fails of course.)

[taufik-nurrohman]

Create a HTML <form><input type="email"> <button type="submit">Test</button></form> then paste the example there. If it does not trigger invalidation, then it should be considered to be added into the specifications.

[wooorm]

(The local GFM highlighter fails of course.)

It assumes GFM, in which case, that’s a user mention.

<@wooorm>

<@wooorm>

---

There are infinite examples of things that don’t work.
But there’s no space for infinite examples.
In this case, autolinks, it’s a very very strict regex grammar.
That regex starts with a character group that does not include @, so your examples cannot match.
So, why? Can you make an argument as for why?

[Crissov]

Some authors expect user mentions like @user to work even without angular brackets. They only make sense within a site usually. Systems that support those often also recognize and hyperlink plain email addresses. Users might assume that this also applies to other universal user handles that include a domain name, i.e. Bluesky/AT Protocol and Mastodon/Fediverse, but not X/Twitter or Facebook, Instagram etc.

[wooorm]

Feels a bit weird to me.

If some platform extends CommonMark with, say, mentions, then that platform should document how that feature integrates with other features?
GFM tables or math extensions are also popular, yet, I do not think we need tests here that show that tables do not work, and how they all do not interfere with all the CommonMark features?

I also do not see how this example would help the users in your case: I doubt those users would check how mentions do not work, in the CM spec.

It sounds a bit like you work on some platform that does mentions, and you have a user that asked about how those mentions work together with CommonMark?

[Crissov]

The final two examples in that section, currently 611 (vs. 594) and 612 (vs. 604), show plain URL and email address to exemplify that these are not recognized as links in vanilla CM. How's what I'm asking for all that different?
I'm pretty sure the spec contains other invalid examples that are valid in some extensions and were included with that in mind.

For what it's worth, it doesn't affect me at all. I just think this makes sense to have.

[wooorm]

How's what I'm asking for all that different?

Right, it’s not quite different. There are already test cases. Those last 2 are about < and >. The earlier ones about the regex.
I don’t see the need to add more examples that do not match the regex. Or at least not particularly this one. Maybe someone else has a different opinion.