Description

Describe the bug... The subscript markup, see reference,,44,, (produces "see reference₄₄") works great in most cases. But there are certain places where it totally screws up. Esp. when trying to produce subscripts in mathematical excerpts (where "indexing" is displayed as a subscripted i,j, for examlpe, rather than programming language custom of [i][j] or [i,j].

Steps to reproduce

Place the following markup in your text...

T1 is cv,,1,0,, pointer to cv,,1,1,, pointer to ··· cv,,1,n−1,, pointer to cv,,1,n,, T

... and this is what you get:

T1 is cv_1,0 pointer to cv_1,1 pointer to ··· cv_1,n−1 pointer to cv_1,n T

Pretty much it looks like most of what I didn't want subscripted is a subscript, and what I did want subscripted was normal text.

Hmmm... I also just noticed that in the code box, the - in n-1 shows up as a solid rectangle. Anyone else see this?

• I don't see the code box rectangle in firefox -- ReimarBauer 2008-06-09 11:23:33

Example

So that this bug report still makes sense after a possible fix, I'm attaching a screen shot:

Component selection

markup parsing or HTML rendering

Details

Workaround

• Don't use comma(s) in subscripted text.
• Don't use subscript text longer than 40 chars.

Discussion

The subscript parsing before the fix was broken for cases when you have a comma in the subscript or when your subscript text is longer than 40 chars. It could lead to some subscript starts being ignored and the intended subscript end being used as a start of some unintended subscript range (that unintentionally ended at some other subscript start).

Plan

• Priority:
• Assigned to:

• Status: fixed by http://hg.moinmo.in/moin/1.7/rev/56e6073b2e23 - please test it. If the fixed regex has less problems, we should backport this to 1.6.

CategoryMoinMoinBugFixed