Item8694: [[*formatting*]] in links is a little broken

Which is a shame, and bites users often.

You need to ensure there are no formatting symbols (*, =, _ etc) against either the beginning or ending brackets.

[[ *this* works ]]

this works

[[*this* doesn't]]

this doesn't

Work-around is obviously the space, but from the user's perspective, this experience just adds to Foswiki's quirkiness.

Is this a known limitation in the parser? Or should it be an easy fix?

-- PaulHarvey - 11 Mar 2010

Commenting is disabled while not logged in

I tried to fix this by adding new STARTEM/ENDEM regular expressions to match formatting inside of squabs, such as [*strong* link] or [link *strong*] however the unit test shows that it breaks one other condition - FormattingTests::test_squabbedEmmedTopic - which tests an italics link which ends in an underscore:

_text with [[H_]] link_

So I'm not sure this is a good fix to apply.

our $STARTWW = qr/^|(?<=[\s\(])/m;
our $ENDWW   = qr/$|(?=[\s,.;:!?)])/m;
our $STARTEM = qr/^|(?<=[\s\(])|(?<=\[\[)/m;
our $ENDEM   = qr/$|(?=[\s,.;:!?)])|(?=\][\]\[])/m;

used later as:

    $text =~ s/${STARTEM}==(\S+?|\S[^\n]*?\S)==$ENDEM/_fixedFontText($1,1)/gem;
...
    $text =~ s/${STARTEM}==(\S+?|\S[^\n]*?\S)==$ENDEM/$1/gem;

-- GeorgeClark - 18 Aug 2010

The actual fix was to add the rendering regex statements into the processing for the Link text. This way the link text is rendered for TML separately, and avoids the issue encountered above. Not committing to 1.0.10, this needs a more thorough test.

-- GeorgeClark - 19 Aug 2010