Description: ------------ Basically the problem is simply that the URL parsing is done before the ColorTewxt parsing in the default rules list, this means that ##red|red text## is interpreted as a link to the anchor #red|red... this can be easily fixed by moving the ColorText Parser before the URL parser in the rules array.

Kungfoocoder is correct in describing the source of the bug. However, changing the rule order (which is an easy fix) will probably have negative consequences on parsing of other rules; wiki rule parsing is pretty dynamic, and changing one usually has effects on the others. Thus, the "better" fix is to work with the URL parsing regex, which I will do.

REQUEST FOR COMMENTS It turns out there is no good fix for this problem. The use of a single hash-mark for same-page anchors has a number of problems: (1) easy to confuse with numbered- list markup, (2) confuses the color text rule, (3) tries to make links out of normal-use numbers, e.g., "Rule #12" or "Reason #88". So my proposed "fix" is to not allow the shorthand method of "#anchor" to refer to a same-page named anchor target. Instead, you'll have to use the previous markup of "PageName#anchorname" (even if it's on the same page). Do any of the Text_Wiki users have a serious problem with this? If so, please email me directly, pmjones@ciaweb.net; if I don't hear back in 24 hours I'll commit my fix as described above.

Well, for my own thoughts, I think that this is a perfectly acceptable solution. What may also be usefulis some way to easily automatically generate a list of overlapping regexes, so that this sort of thing can be more easily detected, since (as you say) the order of matching should not be important.

This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on pear.php.net. In case this was a pear.php.net website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. Kungfoocoder suggested that an automated test of the overlapping regexes would be useful; I agree. However, I am not bright enough to quickly figure out how that would work. I would be very happy to hear suggestions for automated testing of the parsing rules. :-)