A quick fix is to percent encode the troublesome characters, but the underlying issue is in org-link-any-re which is defined in org-link-make-regexps which is what org uses to find the next link. Some improvements might be possible for some of the edge cases there, but a complete solution for bare urls is not possible due to conflicts with native org syntax.
Org doesn't handle these cases well because in some cases org's own syntax takes priority over url syntax at the moment adding bare url syntax as part of org syntax is something that could be considered. However, I would suggest against that because it will taint any org parser in the future by forcing it to implement full url parsing at arbitrary positions in paragraphs, which adds a lot of complexity. I also suggest against it because org already has clear ways to demarcate links using <> and [[]] which are guaranteed to behave correctly even in cases where org syntax will always take priority. For example with https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_[[Savannah,_Georgia]]. > It might be worthwhile to issue an warning each time a url is written in > an org file without enclosing brackets < > or [[ ]]. Unfortunately warning on links without < > or [[ ]] will generate countless annoying false positives for anyone who doesn't hit this edge case. Maybe a separate function could be added to org lint that would not run all the time?
