For the next #Conversations_im release I’m refactoring how URIs are linked / made clickable. I’m adding a bunch of URI schemes like tel and mailto on top of the existing xmpp, http(s) and geo but removing support for "things that look like web URLs but aren’t actually URIs" (like 'example.com') to avoid some false positives.
Once the 2.18.0-beta comes out tomorrow or so let me know if you see things that isn’t matched and should be matched or vice versa.
Guus der Kinderen
in reply to Daniel Gultsch • • •mistersixt
in reply to Daniel Gultsch • • •Ténno Seremél’
in reply to Daniel Gultsch • • •Guus der Kinderen
Unknown parent • • •Buntbart
in reply to Daniel Gultsch • • •docs.taler.net/taler-merchant-…
4. Merchant API Tutorial — GNU Taler
docs.taler.netallo
Unknown parent • • •Maybe like this?
.*[^.)]$
(Replace .* with the actual regex)
And I would vastly prefer an URI ending in ")" being a false negative over many URIs in parentheses being a false positives.
@guusdk
allo
Unknown parent • • •Right ... I guess there we're at the edge cases.
If I were looking for a heuristic, I would say that if the URI has ( or ) before the end, then it can have one at the end, otherwise one can assume that it does not belong to the URL. But I can see how you can find more and more edge cases in such heuristics.
@rakoo @guusdk
allo
Unknown parent • • •The computer scientist in me says you can't find matching parentheses with RegEx.
The programmer in me says look for a solution that is "good enough". An idea that would cover a lot of cases would be, for example, to assume that a URI can contain at most one pair of parentheses. The few counterexamples are rare, and they are then the rare false negatives one has to accept.
@rakoo @guusdk
rakoo
in reply to allo • • •@daniel @guusdk