Testing with #6542 surfaced a crash scenario, caused by formatted links
that had URLs in the display text, for example
[mean example - https://osu.ppy.sh](https://osu.ppy.sh)
In that case the outer Markdown link would get picked up once, and then
reduced to the link text when looking for other links, leading to it
being picked up again the second time when the raw link is found.
Add a check in the raw link parsing path that ensures that the found
URL is not a part of a bigger, pre-existing link.
While reviewing #6542 it became apparent that there was another Markdown
link format variant, used in comments that came from the web API, called
the "inline link" style. It allows to specify the tooltip title within
the actual URL portion, as such:
[link text](https://osu.ppy.sh "tooltip text")
Add tests with a couple of easy and trickier examples of such a format.
Moreover, add a new edge case of a Markdown link with a link inside
the display text, which during tests was detected to be problematic.
Allow users to put both balanced round parentheses, as well as
unbalanced escaped ones, in old style link text. The implementation
is the same as for Markdown and new style links, except for swapping
all instances of
\[\]
to
\(\)
for obvious reasons (different type of parenthesis requiring escaping).
Tests also included.
Allow users to put both balanced brackets, as well as unbalanced
escaped ones, in Markdown link text. The implementation is the exact
same as in the case of new format links.
For completion's sake, tests also included.
For users to be able to add square brackets inside of links using
the new format, the regular expression used for parsing those links
contained a balancing group, which can be used for matching pairs
of tokens (in this case, opening and closing brackets, in that order).
However, this means that users could not post links with unmatched
brackets inside of them (ie. ones that contain single brackets, or
a closing bracket and then an opening one). Allow for escaping opening
and closing brackets using the backslash character.
The change substitutes this old fragment of the regex in the display
text group:
[^\[\]]* // any character other than closing/opening bracket
for this one:
(((?<=\\)[\[\]])|[^\[\]])*
The second pattern in the alternative remains the same; the first one
performs the escaping, as follows:
(
(?<=\\) // positive lookbehind expression:
// this match will succeed, if the next expression
// is preceded by a single backslash
[\[\]] // either an opening or closing brace
)
Since the entire display group is matched, unfortunately the lookbehind
expression does not actually strip the backslashes, so they are
manually stripped in handleMatches.
As demonstrated in the unit tests attached, this also allows balanced
brackets to be mixed with escaped ones.
