Grace to this powerful line of code, I have been able to build the kernel of my wiki parser engine (http://epsilonwiki.free.fr) as explained in this page : http://epsilonwiki.free.fr/index.php?view=parser .

Thank you a lot.
Alain Marty

I would like to create some regular expression to highlight syntax code. In my code, the variables are defined inside brackets [var]. (I can put variables inside another ones, [var[i]])

I have some problems with nested brackets.

I’m using /\[(.*?)\]/g but for [[%1]stack[i]] , ‘stack’ and the last bracket is not coloured.

Any help will be appreciated

Thanks in advanced

Unrolling Steve’s <<example>> regex…
/<<[^<>]*(?:(?:(?!<<)<|(?!>>)>)[^<>]*)*>>/

Unrolling Scott’s <tag>example</tag> regex…
while (str != (str = str.replace(/<(\w+)\b[^>]*>([^<]*(?:(?!<\/?\1\b)<[^<]*)*)<\/\1>/g, "$2")));

But more importantly, these fix a rather nasty PHP bug…
The regex constructs recommended in the original post (and the ones from the comments which follow), lead directly to segmentation-fault problems when parsing semi-longish strings with PHP. This type of regex construct results in a lot of recursive calls in the PCRE library which quickly results in a stack overflow (and segmentation fault) when applied to a long subject text. And the length of subject text which causes the overflow is directly related to the stack size of the executable linked with the PCRE library: typically PHP.EXE (the command line utility) or HTTPD.EXE (Apache web server) on a Windows box. PHP.EXE is typically built with an 8MB stack and HTTPD.EXE is built with a 256KB stack. My testing reveals that Scott’s HTML tag matching regex and Steve’s improved version both generate a stack overflow and seg-fault when applied to a mere 673 byte subject string when the PHP executable has a 256KB stack (i.e. Apache running on Windows). When the PHP executable has an 8MB stack executable (which is the typical value for Apache on Linux boxes), these regexes blow up with a 22999 byte string. And Steve’s original <<example>> regex also blows up with similarly sized strings. The improved regexes I provided above do not suffer this limitation and happily work with subject strings up to 26MB regardless of the executable stack size.

The Drupal community recently wrangled with this problem (which is how I became intimately familiar with the issue) – you can read about that here: Optimize CSS option causes php cgi to segfault in pcre function “match”. For details on the PCRE stack usage issue see: PCRE DISCUSSION OF STACK USAGE.