Problem With the WordMatch Matching Feature

[gohrner]

WordMatch is only very tersely documented in the README.md file and - from my point of view - its use or non-use leads to very surprising results which even hamper autolink's versatility.

WordMatch is explained as

WordMatch - If true uses the \b word boundaries

There's no additional anchoring of the Pattern documented.

So first of all, I wonder why a special parameter is necessary here at all, as from the description it should be equivalent to wrapping the Pattern in \bs - which is even less to type than /autolink set BlaBla WordMatch true...

However, it also works very surprisingly:

/autolink add TEST
/autolink set TEST Pattern (?i)test
/autolink set TEST Template _ok_

Now check the following results:

test

=> is replaced just fine

Mytest

=> is NOT replaced - why? A non-anchored pattern should match in a string, independently of adjacent characters

This is a test.

=> is replaced just fine

This is a test:

=> This is NOT replaced!

Now let's enable WordMatch and check the results:

/autolink set TEST WordMatch true

test

=> replaced again, as expected

Mytest

=> not replaced, which is now expected

This is a test.

=> replaced again, which is fine

This is a test:

=> Woah - now it actually IS being replaced. Why?

So it really looks as if a Pattern without WordMatch still is somehow anchored, but it's not documented how.

Also I have an actual problem with autolink due to this behaviour: I want to match Bugzilla numbers with a leading hash symbol and turn them into links.

So the Pattern looks like #(?P<bugzilla_id>[0-9]+) and the Template something like [#${bugzilla_id}](http://bugzilla.example.com/show_bug.cgi?id=${bugzilla_id}).

However, if someone now writes:

Please see #1234: It's causing us trouble.

the Bugzilla ID is never replaced. Without WordWrap the Pattern does not match due to the trailing :, and with WordWrap enabled the Pattern does not match as there's no word border before the #.

I could obviously work around this with some regexp magic, but this really was surprising to me and looks like a bug. I'd even not know which behaviour I'd be working around exactly, which makes it more difficult to find a really appropriate workaround which covers all cases. ;)

And such workarounds makes the Patterns (and probably also Templates) more complicated than necessary.

[onno-ole]

Just stumbled upon the same error, did you find a workaround other than making unnecessary complicated patterns?

[gohrner]

Just stumbled upon the same error, did you find a workaround other than making unnecessary complicated patterns?

Unfortunately, no. :-(