-
Notifications
You must be signed in to change notification settings - Fork 95
-
Notifications
You must be signed in to change notification settings - Fork 95
URL regex doesn't recognise important TLDs like .cat #3
Comments
There are also other problems with the regex. Hosts such as http://localhostr.com get detected as http://localhost/ |
Also .pro is affected. |
Bump. |
Why not just simplify the regexp? The current one leads to nowhere. Why not use something like (pcre syntax that is) |
The aim of the regex has previously been to match only plausible URLs, not anything that could conceivably be a URL; I'm guessing this is what people expect (it's what I expect). It's customisable; if you want to use something more liberal feel free. Also, no, the regex engine supports basically nothing. #4 is to fix that, but it's hard work. |
Everything that conceivably is a URL is also a plausible URL in my opinion. So, if anyone is interested: In contrast to the very complex default regexp which needs a lot of maintence it allows me to click the following URIs: www.example.newgtld I also giggled at |
Finally found a case where this breaks horribly: * attempt launch an invalid url * we panic, and think we can never launch a url again * future non-http urls get run with the browser, with mixed results While I could fix that actual bug, I'd rather remove the panic code, which should never be being hit anyway.
I've added a default option of @incognico's suggestion, and liberalised the "classic" default a bit. I've additionally removed the nasty browser detection code, as this was just generally broken even launching urls like "www.google.com". |
Finally found a case where this breaks horribly: * attempt launch an invalid url * we panic, and think we can never launch a url again * future non-http urls get run with the browser, with mixed results While I could fix that actual bug, I'd rather remove the panic code, which should never be being hit anyway.
Finally found a case where this breaks horribly: * attempt launch an invalid url * we panic, and think we can never launch a url again * future non-http urls get run with the browser, with mixed results While I could fix that actual bug, I'd rather remove the panic code, which should never be being hit anyway.
Finally found a case where this breaks horribly: * attempt launch an invalid url * we panic, and think we can never launch a url again * future non-http urls get run with the browser, with mixed results While I could fix that actual bug, I'd rather remove the panic code, which should never be being hit anyway.
Finally found a case where this breaks horribly: * attempt launch an invalid url * we panic, and think we can never launch a url again * future non-http urls get run with the browser, with mixed results While I could fix that actual bug, I'd rather remove the panic code, which should never be being hit anyway.
Hovering URLs like http://nyan.cat/ and clicking take you to http://nyan.ca/ , as the .cat TLD isn't recognised.
TLD specific code should probably be removed anyway, due to the introduction of arbitrary TLDs.
The text was updated successfully, but these errors were encountered: