Syntax highlighting wrong

[gsurrel]

Pandoc takes into account the code written in LaTeX or HTML for the formatting. Therefore, such a snippet shouldn't be highlighted as such:

According to \cite{a.j,_marley_m._johnson_j.t._bigger}, Pandoc is awesome.

# Other part

We can have some nice equations:

[
\hat{\mu}= \frac{\sum_{i=1}^n w_i RR_i}{\sum_{i=1}^n w_i}, ,,,,,,,, \frac{1}{\hat{\lambda}}= \frac{1}{n} \sum_{i=1}^n w_i \left( \frac{1}{RR_i}-\frac{1}{\hat{\mu}} \right)
]

If it's not clear enough, the bold highlighting runs from the first _in the \cite to the first _in the equation. I guess that if we are in a LaTeX environment (i.e in \command{ *here* }), we should apply the highlight only in this block: starting an highlight in \command{ should finish before the }.

(I made the code above copy-pastable to reproduce the problem), even though Github has processed the Markdown)

[leipert]

Hey. I am well aware of this problem...

Actually the code highlighter of atom has a big caveat for blocks as it is only able to parse per line. Consider the following source:

__bold__
__this
is
bold__
__actually
not

bold__

This is problematic and code highlighting does not even work on github.com, as you can see.

bold
this
is
bold
__actually
not

bold__

At the moment it is implemented, that bold and emphasis are block environments. So once you have a starting _ or * it searches for a closing match and marks everything between as bold / emphasised.

The only alternative to the current parser would be if it would be only allowed to use bold / emphasised text inline, so that

__this
is
bold__

would not be recognised anymore.

[leipert]

BTW: The problem also exists with the official language-gfm package. And I broke my head over regex searches for over 12 hours to fix it.

[gsurrel]

OK, I'll stick to a <!-- markup clean_ --> to make it end "properly". Not satisfying but at least, not coloring huge chunks of my document.

Thanks

[leipert]

@gsurrel Whoa. That is neat. Never thought of that one before.
I joined the discussion of atom#44 which also discusses this problem.
Therefore I close this issue right here as I take a lot of the
source code from there and once there is a fix, it will be fixed in language-pfm automagically :)