#21 Fix: Doesn't auto-detect single symbol (sub)domains

[Anonymous]

Here are a few examples of valid links that won't get properly autodetected (Try it on the on the live demo)
* http://x.org
* http://www.x.org
* http://3.bp.blogspot.com/_mmBw3uzPnJI/Sy_O83XCaTI/AAAAAAAA7uc/mv1jV4amYx0/s1600-h/useless_product_13.jpg
* http://i.imgur.com/4Z3Co.jpg

To allow single-letter domains/subdomains I fixed it like this:
Go to line 1273 and change this:
(?: (?: [a-zA-Z0-9-]{2,} \\. )+
... Into this:
(?: (?: [a-zA-Z0-9-]{1,} \\. )+

I can't think of this having any weird side effects? I assume it's set to minimum 2 symbols because you thought there's a min limit for hostnames?

Keep up the good work! I've been running it for a few weeks on one of my sites and no one's complained about anything else. :)
// Fredrik Kilegran, Sweden

[phantom-inker]

It's not that there's a minimum limit for hostnames; it's that allowing single-character matches --- just floating in text --- would result in the autodetector grabbing things that aren't actually hostnames. For example, while matching x.org is reasonable, matching U.S.A. and U.K. or e.e.cummings [sic] as hostnames would be bad. I've even seen some weird abbreviations in German that are of the form A.BCD.EF, and those definitely aren't hostnames either.

So the rule is set that way for a reason for plain text. That said, anything preceded by http:// or https:// or ftp:// should probably be treated as a hostname regardless, so I may update the rule to allow single-character hostnames for full URLs.

[phantom-inker]

Actually, the more I look at the existing code, the more I think this change will work okay. The URL-detector is already strict enough to recognize a known TLD and protocol, so I think I'll update this accordingly in the next release. Thanks for the suggestion!