# I have noticed a bug formatting equations and was wondering if someone could help?

##
If we have a definite integral, after the integration the answer is typically put in square brackets with a pair of limits at the right end, like this:

#int_(lower)^(upper)dx=[x]_(lower)^(upper)#

However, if I have two sets of square brackets on the same the line and require the use of curved brackets in the limits, then it does not format properly and I don't why, for example:

#[x]_(lower)^(upper)+[y]_(lower)^(upper)#

Notice this time the equation has not formatted and I am not sure why? The underscores I entered in the text to make "lower" a subscript have also vanished.

It only seems to happen if you have two sets of square brackets and curved brackets around the lower limit of the second set of square brackets. If I didn't have those curved brackets it works:

#[x]_(lower)^(upper)+[y]_l^u#

But I need those square brackets to put things like fractions inside the limits.

I don't why this is happening and was wondering if someone could help?

If we have a definite integral, after the integration the answer is typically put in square brackets with a pair of limits at the right end, like this:

However, if I have two sets of square brackets on the same the line and require the use of curved brackets in the limits, then it does not format properly and I don't why, for example:

Notice this time the equation has not formatted and I am not sure why? The underscores I entered in the text to make "lower" a subscript have also vanished.

It only seems to happen if you have two sets of square brackets and curved brackets around the lower limit of the second set of square brackets. If I didn't have those curved brackets it works:

But I need those square brackets to put things like fractions inside the limits.

I don't why this is happening and was wondering if someone could help?

##### 1 Answer

Ah yes, a classic!

#### Explanation:

The bug is actually only limited to the Preview section--once you submit the answer, the formatting works fine (as you can see in the question description).

The idea is that having multiple underscore symbols one after the other messes up the formatting in the preview because underscore symbols are also text modifiers.

So, for example, when you write something like this

without hashtags[x]

(lower)^(upper)+[y](lower)^(upper)

with hashtags

#[x]_(lower)^(upper)+[y]_(lower)^(upper)#

the math formatting will not work in the Preview section because the editor interprets the two underscore symbols as text modifiers.

More specifically, it converts everything **after** the first _ symbol and right **before** the second _ symbol to *italics font*--that is why the two _ symbols seem to disappear in the Preview section.

To avoid this problem, leave a blank space after every _ symbol that you use.

without hashtags[x]

(lower)^(upper) + [y](lower)^(upper)

with hashtags

#[x]_ (lower)^(upper)+[y]_ (lower)^(upper)#

Notice that both versions work once the answer is submitted, but only the second one works in the Preview section.

Finally, the editor is kinda picky at times with how it interprets the two (or more) underscore symbols, which is why some versions seem to work in the Preview while others do not.

So when you see that a syntax is not showing up properly in the Preview section, just add a blank space after every _ symbol and it should work.