New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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: