In DText links, ) are only considered part of a URL if a ( was found previously in that URL, preventing URLs inside parentheses from being mangled. However, if another character is included immediately after that ), it instead considers the ) part of the URL.

These characters simply cause the ) to become part of the URL:

test!
test.
test,
test;
test

Additionally, these characters are even weirder, considering both the ) and the next character part of the URL, but then printing the ) afterward:

test:
test
test
test
test
test
test

Expected output for all of those is that neither the ) or the next character are part of the URL, instead being printed afterward in plain text.

With only whitespace after the ), it works as expected:

See?)

Is being able to use parenthesis to end the links supposed to happen? 'Cause I always ended my links like so , space between the punctuation so it doesn't mix up with the URL.

Let's see if this works.

This has been a bug this entire time? :o

Huh. I always assumed that this was intentional, since urls can contain parentheses.

^{_{http://imgs.xkcd.com/comics/(.png[/sup][/sub]}}

Genjar said:
Huh. I always assumed that this was intentional, since urls can contain parentheses.

Well, if there's a period or whitespace after it, it should ignore the parenthesis. I kind of would like the URL to have to be contained, though, so that we can selectively tell it what the url consists of.

Shouldn't you be using the bug template for this, or is it optional if just including all relevant information?

I'm not sure the first examples really represent a bug (except last one), those sound like a fairly valid but strange URLs, albeit the second set is definitely strange. Also might be interesting to actually display how to reproduce the bug e.g.:

-> test) = test:

Anyway I would suggest the following optional DText format that I have honestly tried multiple times even knowing that it doesn't work, which could also "solve" these bugs:

-> link text)# ≈ link text )#

I.e. using quotes for both link text and link address; a starting " for the link address will continue link parsing until another " is found (except maybe for LF/CR). Only problem would be another " being part of the URL, but is a minor problem.

Chessax said:
Anyway I would suggest the following optional DText format that I have honestly tried multiple times even knowing that it doesn't work, which could also "solve" these bugs:

"link text":"https://e621.net/")#

-> link text)# ≈ link text )#

I.e. using quotes for both link text and link address; a starting " for the link address will continue link parsing until another " is found (except maybe for LF/CR). Only problem would be another " being part of the URL, but is a minor problem.

+100 for this, I was actually going to suggest the exact same thing but for another reason.

I was trying to fix the link to https://en.wikipedia.org/wiki/Tom_Lister_Jr. on the finnick wiki page, but the trailing . was not regarded as part of the URL.

Siral_Eurgh-xan said:
Is being able to use parenthesis to end the links supposed to happen?

Genjar said:
Huh. I always assumed that this was intentional, since urls can contain parentheses.

We intentionally made it end link parsing when encountering an un-opened ) at the very end of a URL, since the chances of that being part of the URL are vastly smaller than the chances of someone putting a link inside of parentheses.

Chessax said:
Shouldn't you be using the bug template for this, or is it optional if just including all relevant information?

I'm not sure the first examples really represent a bug (except last one), those sound like a fairly valid but strange URLs, albeit the second set is definitely strange. Also might be interesting to actually display how to reproduce the bug e.g.:

"test":http://example.com):

-> test) = test:

Anyway I would suggest the following optional DText format that I have honestly tried multiple times even knowing that it doesn't work, which could also "solve" these bugs:

"link text":"https://e621.net/")#

-> link text)# ≈ link text )#

I.e. using quotes for both link text and link address; a starting " for the link address will continue link parsing until another " is found (except maybe for LF/CR). Only problem would be another " being part of the URL, but is a minor problem.

I tried to use the template but the examples were a bit too complicated to fit into "actual" and "expected" categories.

Again, technically correct URLs in the first part, but extremely unlikely compared to someone just putting a link inside parentheses.

I'm sure they know to look at the DText source to see what was entered to produce the bug :P

That would be a much better format for links.