Unify handling of opening and closing parentheses

[ThiefMaster]

#24 added support so a message like (see GH-1234) can have GH-1234 autolinked, but the other way round doesn't work, so (GH-1234 might solve your bug) won't be autolinked.

This can already be worked around by enabling DisableNonWordPrefix and then using a custom regex to specify the boundary, but I think more consistent default logic makes more sense.

[jespino]

Yes, that would be great, I have to think about it, maybe we can have another flag to allow that or a special field to specified a list of valid extra prefixes, like (, {, , or whatever.

[jasonblais]

FYI @levb @jfrerich This is one bug which would get noticed and reported as an issue in a GA release

[levb]

I'd appear that post 1.0 we probably want to change the semantics as:

[x] Match entire word
[x] Word start separators:
        [x] white space
        [x] other:  <  ([{  >
[x] Word end separators:
        [x] white space
        [x] other:  <  )]}  >

so the config entry might look like this:

{
    "Pattern": ...,
    "Template": ...,
    [ "DisableMatchEntireWord": true, ]
    // Or...
    [ "StartWord": "character class regexp, complete with whitespace as needed", ]
    [ "EndWord": "character class regexp", ]
}

For 1.0 I'll see if I can quickly add the ( to the prefix list to address this specific issue.

[andrey-yantsen]

Wasn't it fixed after #67 and release of v1.1.0?

[jasonblais]

cc @levb on above note from Andrey

[levb]

@andrey-yantsen #67 failed to be backwards compatible, but #71 introduced the WordBoundary[=true] link property to use the more standard \b word boundaries. If you turn it on, it should solve the ( issue.